On Sun, 2009-11-08 at 19:43 +0000, Chris Cannam wrote:
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:
On Sun, Nov 8, 2009 at 7:18 PM, Nedko Arnaudov
<nedko(a)arnaudov.name> wrote:
Chris Cannam <cannam(a)all-day-breakfast.com>
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.
Then it's X specific. I'd rather implement the embeddey part in a
library that can take a void* pointer to a somethingorother (where the
type is specified) and deal with the details.
Having a bunch of X specific junk in hosts isn't that much more
palatable than a bunch of Gtk/Qt/whatever specific junk anyway.
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.
Obviously there is ;)
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.
It is an extension by which you can easily find a UI of some type for a
plugin. No more, no less. What is possible with those types, or what
types are used in practice, is (deliberately) an orthogonal problem.
-dr