[LAD] Qt GUI for LV2 Plugin

Jeremy jeremybubs at gmail.com
Tue Jun 15 16:30:26 UTC 2010


On Tue, Jun 15, 2010 at 7:34 AM, Paul Davis <paul at linuxaudiosystems.com>wrote:

> On Tue, Jun 15, 2010 at 3:49 AM, Jeremy <jeremybubs at gmail.com> wrote:
>
> > Hi,
> > So I've written a GUI, and I've gotten a better understanding of how the
> Qt
> > framework works.  It seems to me that all that would be necessary is for
> the
> > host to pass a pointer to a QWidget, which the plugin adds itself to, and
> > the rest can behave exactly like the ui:GtkUI.  If I'm not mistaken, all
> > that would be necessary it to write a new rdf file.
>
> far from true. That would be enough to make the GUI work in a Qt host.
> But the problems of making it work in a GTK host, or vice versa,
> making a plugin using ui:QtUI work in a Qt host, would remain.
>
> torben, dave and i had some detailed discussions on IRC recently about
> some new ideas on how to make this work, but i don't think its easy
> and its not likely to appear any time soon.
>
> nothing like the plethora of choices implied by open source
> development to royally screw up basic things.
>

How about this idea?  The plugin is responsible for creating its own window
if the host doesn't know how to do it.

So for example 1, a Qt application looks at the rdf and sees it is a Qt GUI.
 It opens up a new internal frame, and calls the plugins intantiation
function.

example 2, a Gtk application looks at the rdf file and sees it is a Qt GUI.
 It calls the plugin's "createWindow" method, which creates a standalone
window to host the widget, and returns the necessary callbacks.  Then the
host calls the plugin's instantiation function with the newly created window
as an argument.

This way I can create a new toolkit and it will work with any existing
(well, after this is implemented) host, but be non-integrated.  It also
allows tight integration with hosts in the right circumstances, where it
might be very useful (Qt GUIs in LMMS for example).  It would even allow the
qtg or gtq embedding to be easily implemented at a later point and work with
the existing system.

This has all the benefits of an external UI, and all the benefits of an
internal UI (when possible).

Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20100615/33da87dd/attachment.html>


More information about the Linux-audio-dev mailing list