[LAD] How to develop guis for LV2?

David Robillard dave at drobilla.net
Sun Nov 8 20:20:10 UTC 2009

On Sun, 2009-11-08 at 19:43 +0000, Chris Cannam wrote:
> On Sun, Nov 8, 2009 at 7:25 PM, David Robillard <dave at 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 at arnaudov.name> wrote:
> >> > Chris Cannam <cannam at 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.


More information about the Linux-audio-dev mailing list