short-circuiting the main event loop

[Paul Davis <paul linuxaudiosystems com>]

there's a cross-industry effort going on right now for those of us
involved in audio software. its an attempt to define a common,
cross-platform audio+MIDI "plugin" API. one of the sticking points, as
ever, is how to handle GUIs. the situation with X Window is causing us
some serious grief, and i'd like to get a handle on where we are
today, in GTK+ 2.X.

the specific problem that we face is the belief present in GTK+ 1.X
(for sure), Qt, FLTK and others that the toolkit owns the event
loop. this is completely incompatible with the idea of having plugins
using one toolkit running inside a "host" that uses another. 

does GTK+ 2.X have an entry point yet where X events that pertain to
windows controlled by GTK can be fed, without any GDK/glib main loop
running at all? i know that for this to work, other toolkits need to
provide the same thing, but i thought i should start by asking my
favorite tookit :)

i know that the glib io stuff would not work in such a situation, but
since wrappers for this have now been removed from the GTK/GDK API
(right?) that's OK; plugins would be allowed to use GTK/GDK but not
glib (because glib assumes that *its* event loop is running, sigh).

any news or comments on this issue? although its understandable that
toolkits weren't written with this in mind, it has led to a truly
appalling situation for audio software developers on linux (and *nix
generally). right now, plugin developers and "host" developers have to
agree on which toolkit to use, and as we all know from the KDE/GNOME
situation, that isn't realistic.

--p