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, >k_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.me...@suse.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
