Re: gdk threads ...

[Michael Meeks <michael meeks suse com>]

Hi Paul,

On Mon, 2012-05-21 at 08:03 -0400, Paul Davis wrote:
> your code must have an event loop abstraction, at some level. if it
> doesn't then in 2012 there's nothing else to talk about, really.

	Of course it has an event loop abstraction, it has had that for decades
- it's not as clean & complete as glib's, but ... How are you imagining
writing a serious X application without a main-loop ? I've never seen
one at least :-)

> you might use glib for this (which i would note can be done even when
> *not* using GTK) or you might use something else.

	We backend onto glib's under gtk+.

> the only real requirement is that whenever one of the event loops
> within the application wants to do something with GTK/GDK, it does so
> by injecting an idle callback into the GTK/GDK event loop, and *not*
> by calling the GTK/GDK functions directly. 

	Sure; but this "only real" requirement is not that trivial; neither is
it pleasant to read or maintain - for the ~800+ calls we make prefixed
gtk_ I suspect it will also perform pretty poorly. Now I think about it,
we can't special-case the main thread - everything has to be proxied to
the GUI worker thread - since we can't tell when the 'main' thread may
be busy on a long term basis (incidentally hence the existence of poking
the GUI from a thread in the first place ;-).

> now from my perspective, not using a unified event loop abstraction
> (such as glib's) all over the place is a headache, but i can see that
> there are reasons to not do this, certainly for now. but i can't see
> any fundamental objection to changing the following pseudo-code:

	It's just software; anything is possible given infinite time. We could
(essentially) create a gtk+/gdk worker thread - and every single API
call would be proxied across to this thread. 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 ? :-)

	At the moment, we don't use gtk+ widgets internally for much, we (try
to) render using the new theming logic, but this is increasingly going
to stop working as animations arrive (I understand). In theory we have a
star-trek thread / apartment model that would let us move our few,
not-much-used except by extensions, component based APIs to proxy their
calls into some "gtk worker thread" that painlessly talks to real gtk+
widgets - it might even be a great show-case of this under-developed
feature ;-) no doubt it would help shake some bugs out.

> the result is a logical program structure that is pointing in the
> right direction even its not there yet.

	Windows, has this rather nice 'SendMessage' abstraction that hides that
synchronous cross-thread blocking fun, so you can do;

void not_gtk_im_context_filter_keypress( GtkIMContext *ctx,
					 GdkKeyEvent *event )
{
	struct {
		GtkIMContext *ctx;
		GtkKeyEvent  *event;
	} pain;
	pain.ctx = ctx;
	pain.event = event;
	// See the SendMessage equivalent:
	return !!gtk_master_loop_send_message(
			&pain, &gtk_im_context_filter_keypress);
}

	On the other hand I am -still- grasping at a benefit that justifies a
radical re-structuring of our gtk+ backends, and attendant code churn,
and curious performance.

	Clearly -everything- is -possible- at some level, but we have a large
number of sizeable investment opportunities in our code-base as-is,
without adding large numbers of new ones ;-)

	Having said that, if someone is willing to leave the clean, sane world
of abstract toolkit design, and wander into VCL and help improve it to
match the new-world-order, then I'm enthusiastic about any arbitrary
change :-)

	ATB,

		Michael.

-- 
michael meeks suse com  <><, Pseudo Engineer, itinerant idiot