On Tue, Jun 15, 2010 at 4:48 PM, Gabriel M. Beddingfield <gabrbedd@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.