8 Nov
2009
8 Nov
'09
3:43 p.m.
On Sun, Nov 8, 2009 at 7:25 PM, David Robillard <dave(a)drobilla.net> wrote:
On Sun, 2009-11-08 at 19:19 +0000, Chris Cannam
wrote:
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.
On Sun, Nov 8, 2009 at 7:18 PM, Nedko Arnaudov
<nedko(a)arnaudov.name> wrote:
How can one possible embed a Gtk widget without... having a Gtk
widget? :) Chris Cannam <cannam(a)all-day-breakfast.com>
writes:
Right, OK, same thing though from this point of view. GTK anything. Because it passes a GTK window, doesn't it?
(Doesn't it?) Which has
no meaning anywhere except GTK.
It passes GTK *widget*. 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