<br><br><div class="gmail_quote">On Tue, Jun 15, 2010 at 4:48 PM, Gabriel M. Beddingfield <span dir="ltr"><<a href="mailto:gabrbedd@gmail.com">gabrbedd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im"><br>
<br>
On Tue, 15 Jun 2010, Jeremy wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


Otherwise, every host has to have a Qt-external-window setup, an<br>
FLTK-external-window setup, a GTK-external-window<br>
setup, etc.  Kind of defeats the purpose of having the external UI, doesn't<br>
it?<br>
<br>
</blockquote></div><div class="im">
wait, isn't the<br>
LV2UI_Descriptor->port_event() and LV2UI_Write_Function() interface toolkit<br>
agnostic? Wouldn't it be possible to have toolkit agnostic host-facilitated<br>
communication?<br>
</div></blockquote>
<br>
Yes, these are.  And these allow plugins to communicate with other plugins.<br>
<br>
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.<br><font color="#888888">
<br>
-gabriel<br>
</font></blockquote></div><br>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.<br>

<br>1. The host, which can directly embed a widget if it is of the right type.<br>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.<br>

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.<br><br>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.<br>

<br>Obviously, if as Paul says there are issues handling events, then this might not work out at all.<br>