Re: gdk threads ...

[Benjamin Otte <otte gnome org>]

On Tue, May 22, 2012 at 10:59 AM, Martyn Russell <martyn lanedo com> wrote:
>
> 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.
>
No, having libraries do invasive jobs that only some applications need
causes work for everyone. You need to make sure _every_ library that
uses GTK uses gdk_threads_enter/leave(). Webkit, libempathy and every
library providing GTK widgets or access to them must be checked -
without having a single use case, so tests need to be explicitly
written on the off chance that LO might want to use it (or might
accidentally use it via dependencies or plugins). That's not even
comparable to putting the feature into a bunch of crappy apps and
having them deal with it.

>> 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.
>
Yes, in terms of UI. But it never ever trickled down into the API
layer. When I started making more API private in GTK 3, people
actually started copying private headers into their projects.
We don't have a culture at all of making our APIs simple and to the
point and avoiding configuration knobs and hooking in everywhere. Our
APIs are the opposite of our UIs.

> 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.
>
But LO has a choice: It can write an ugly cludge of a wrapper that
wraps every GTK API call into a if (!in_main_thread) g_idle_add
(wrapper_for_gtk_func); else gtk_func();
You can pretty much autogenerate it from introspection data if you
want to, which gives you threadsafe access to all of GTK.
Or we could just fix the crappy LO code instead of holding the whole
GNOME platform back because someone might have a proprietary Java
plugin somewhere that uses threads.

Benjamin