Re: embedding GTK<->Qt: they can, can we ?

[Paul Barton-Davis <pbd Op Net>]

>I believe that paper describes out-of-process components. You can
>already freely do that with Bonobo, which like KParts is above the
>toolkit level. However there is no Bonobo implementation for Qt, just
>as there's no KParts implementation for GTK, so the practicality of
>all this is pretty limited.

Two points.

1) The point of the paper was to suggest the use XParts, and then to
   derive KParts from XParts. They note that they *do* have a
   prototype of this working with support for GTK via
   a GtkXPartManager.

2) What interests me is more the in-process stuff.

>In-process components are more complicated. As they say in the paper,
>you have to hack the GLib 1.2 main loop to allow it, and the GLib 2.0
>main loop is so hacked out of the box. GTK 2 should work a bit better
>with Motif and Qt widgets. We will need GtkXtBin and GtkQtBin widgets
>to embed widgets from those toolkits.

So, do I read this as saying that with glib 2.0, we will be able to
(theoretically at least) have the event loop for multiple widget sets
hanging from the same X server connection ? This would be *momentous*
news for the Linux audio development community, and I assume for many
others too. At this time (glib 1.X), I can see no way of doing this at
all, and its been a major stumbling block to the development of 
"native GUI's" for audio processing plugins.

--p