Re: gdk threads ...

[Martyn Russell <martyn lanedo com>]

On 05/22/2012 01:56 AM, Benjamin Otte wrote:
> Michael Meeks<michael.meeks<at>  suse.com>  writes:
> > The unfortunate thing about
> > this design is that every toolkit user gets to re-write a bus-load of
> > boiler plate stubs&  skels and link them into every application. Why not
> > do that, just in a better way, inside the toolkit ?
> (Disclaimer: This is my personal opinion and is in no way related to the opinion
> or future API design of GTK or GNOME - though I try to influence both.)
>
> I've spent a bit of time thinking about the general "why doesn't the framework
> give us the means to do X?" questions as well as the actual use case of
> libreoffice. And I think the answer to your question is "the code should be
> where the problem is" and as your threading model is the problem, the code
> should be with you. You should be the one motivated to improve things and reduce
> code, not GTK.

I believe this is quite illogical.

In short, LibreOffice is just one project being highlighted here (and 
rather a big one at that). I suspect there are many others that won't be 
writing to this list or know about such changes until it's too late.

I've always believed libraries should do the job that *many* projects 
would have to re-implement. It just doesn't make sense from a 
maintenance and bug fixing point of view to have many solutions to the 
same problem scattered around projects when the common denominator (the 
toolkit) could do it right for everyone.

This just causes work for everyone.

> Libs in the general GNOME vicinity have historically taken the "let's export all
> the features we have" approach. You can set everything everywhere. And if you

I actually believed we had the opposite approach in most cases, 
certainly in terms of the UIs for our applications.

> can't, there sure is a signal that you can hook into, capture things and do it
> your way. On the opposite side, libraries like Cairo have taken a different
> approach: A minimal API and very few ways to hook into the system and influence
> what is actually happening.
> I think we should move GNOME closer to the Cairo approach. Reduce the amount of
> API. You can read http://ometer.com/free-software-ui.html for why that's a good
> idea. Just replace UI with API and user with developer in that article.

I will concede there is usually a sweet spot between *libraries* 
becoming redundant because they suit all (and suffer performance or 
other degradation) vs providing enough support for projects using your 
library. Tracker is a great example of this. The 0.6 versions had APIs 
which were not powerful enough, so we came up with libtracker-sparql. 
But, as a result, we now have libraries/frameworks like folks and grilo 
to provide simpler APIs to get your data.

In the end, you could extrapolate from above that we should have a 
separate library to deal with LibreOffice's situation, but if you can't 
actually do that without a patched GTK+, it leaves no choice.

> Now what does that mean for applications that use these APIs that are going to
> be removed? They're doing the same thing the users do when their preferences get
> removed: They either change the way they do things, they stick to the old
> version for as long as possible or they switch to something else. And in the end
> I'm pretty sure everyone in GNOME-land will be happy to help LO become a great
> GNOME application.

LO is one case. I have written applications which have had to deal with 
custom even loops working with the GTK+/GLib event loop for their own 
in-house uses (IPCs, etc). There are just many cases you don't know about.

I advocate async, thread free approaches and think it's a mistake to use 
threads with any UI, but I think it's a bigger mistake to close the door 
on projects that have no choice.

--
Regards,
Martyn

Founder and CEO of Lanedo GmbH.