On Sun, Nov 8, 2009 at 7:25 PM, David Robillard <[email protected]> wrote: > On Sun, 2009-11-08 at 19:19 +0000, Chris Cannam wrote: >> On Sun, Nov 8, 2009 at 7:18 PM, Nedko Arnaudov <[email protected]> wrote: >> > Chris Cannam <[email protected]> writes: >> >> Because it passes a GTK window, doesn't it? (Doesn't it?) Which has >> >> no meaning anywhere except GTK. >> > >> > It passes GTK *widget*. >> >> Right, OK, same thing though from this point of view. GTK anything. > > How can one possible embed a Gtk widget without... having a Gtk > widget? :)
Uh, with an X window or whatever. GTK and Qt are both X toolkits after all. In any case, it doesn't have to be embeddable to be useful -- it only has to be in-process (even if in a separate window) to be better than the DSSI alternative. > Again, to be sure this is clear, there is no "Gtk UI extension". The UI > extension can return a UI of any type (as a void pointer), Gtk just > happens to be one of them. But it's only of any use at all if the host and plugin know what the void pointer points to. Presumably the extension provides a way to communicate that; otherwise, it either really is a GTK UI extension (because there are GTK plugins that use it already, so all hosts must assume the unknown void pointer is a GTK widget pointer), or else it's just a very fancy segmentation fault extension. Anyway, even if you can write plugins using any toolkit and run them in a host that uses any toolkit, I posit that a UI extension in which the UIs only appear if the plugin and host happen to be using the same toolkit is not a very useful one. Chris _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
