[LAD] Qt GUI for LV2 Plugin

[Jeremy]

On Tue, Jun 15, 2010 at 4:48 PM, Gabriel M. Beddingfield <gabrbedd at gmail.com
> wrote:

>
>
> On Tue, 15 Jun 2010, Jeremy wrote:
>
>  Otherwise, every host has to have a Qt-external-window setup, an
>>> FLTK-external-window setup, a GTK-external-window
>>> setup, etc.  Kind of defeats the purpose of having the external UI,
>>> doesn't
>>> it?
>>>
>>>  wait, isn't the
>> LV2UI_Descriptor->port_event() and LV2UI_Write_Function() interface
>> toolkit
>> agnostic? Wouldn't it be possible to have toolkit agnostic
>> host-facilitated
>> communication?
>>
>
> Yes, these are.  And these allow plugins to communicate with other plugins.
>
> However, these functions are executed in the host application's memory
> space.  So, I don't see how it would help in having FLTK widgets hosted by a
> Qt application.
>
> -gabriel
>

I'm not suggesting hosting individual widgets within a foriegn API's frame.
I'm simply saying that it might be possible to abstract the plugin gui
architecture into three parts.

1. The host, which can directly embed a widget if it is of the right type.
2. The translation layer, which can launch a new window to embed the widget
if its toolkit does not work with the host.  The host will still have
generic "main event loop" callbacks to the translation layer, which is
provided by the plugin.
3. The widget, which doesn't have to be aware of how it is hosted, but
simply is given a parent widget to add itself to.

Now, this would mean that you could have "external" type windows in the case
where internal windows aren't going to work, and still retain the "internal"
type process unification, and communication unification.  It would also
allow plugin writers to write a *single* GUI implementation which could
function as both an embedded and external widget, with a *single* method for
communication.  The "translation layer" would only have to be written once
for each toolkit, and then bundled with the plugins that use it.

Obviously, if as Paul says there are issues handling events, then this might
not work out at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20100615/d069dc94/attachment.html>