[linux-audio-dev] Audio s/w ui swallowing

Paul Davis paul at linuxaudiosystems.com
Mon Dec 9 22:52:01 UTC 2002


>On Mon, Dec 09, 2002 at 03:00:19PM -0500, Paul Davis wrote:
>
>> it suffers from several the usual incompatible toolkit problems, but
>> not quite as many. as long as the toolkit allows you to add a foreign
>> window, it could be made to work.
>
>Seeing as this has come up again, I asked on the #gtk+ channel on
>irc.gnome.org the other day about why you can't use gtk+ and qt (for
>example) in the same app, and whether or not it's likely to change.
>They had this to say:
>
><owen> node: Well, really depends on the other toolkit....
><owen> node: And whether you want to share the Display connection or not.
><owen> node: GTK+ is perfectly happy to let another toolkit share its main loo
>p
><owen> node: Metacity is an example of how you can leach of GDK's display
>             connection, but sharing a single display is inherently going
>             to be hard
>
>Has anybody actually tried to get gtk+ and qt working in the same
>application?

its been done.

it was ugly as sin. they did it by writing some new KDE objects to
handle the GTK+ side of things. then they wrote a "white paper" about
it that was enough to put any right-thinking programmer off the whole
idea. it might be *slightly* easier by using GTK+ as the "primary"
event loop, but not much.

but since we want to, as owen said, "leach off a single XDisplay",
this will always be hard. the way i described this over on the VST
plugins list recently was somewhat like this: each toolkit has its own
event loop that gets events from the X server. but it has no idea what
to do with events that are for windows that the toolkit did not
create. what you'd like is some kind of "master event loop" that
allowed to register a event handler for a given toolkit along with a X
Window ID; when events arrive for that window, they are dispatched to
the correct handler. however, this totally messes up the fact that
most toolkits expect to be able to schedule time-based events from
their event loops and also to be able to integrate poll/select-driven
I/O on generic file descriptors (and other kinds of "events") into
their event loops. so yeah, its basically really hard. i could write
this, but it would take me a 3-4 weeks to make it work with even just
GTK and Qt, let alone all the other toolkits. 

worse, all nobody needs it except us wierdos who want to load .so's
that create their own GUIs. the regular world doesn't need this in any
way. 

--p



More information about the Linux-audio-dev mailing list