[linux-audio-dev] plugin GUIs

[Paul Davis]

>On Tue, Nov 18, 2003 at 10:45:40AM -0500, Paul Davis wrote:
>> i offer this as a proof of concept. i believe that our problems with
>> GUIs for plugins are pretty much over, modulo defining some standards
>> as per another recent from me.
>
>Paul,
>
>I freely confess that I do not know how X works.  Can you explain a bit more
>for the dummies (like me) what you've come up with, what it means, and how
>we can use it for the GMPI discussions?

i'm not quite ready for that yet, and trust me i'll post on GMPI once
i am.

what i can say for now is that the XEmbed extension, a relatively
recent extension but present in XFree86 for quite a while, its
designed to allow precisely this to happen in a smooth way. It allows
either of these to be done very simply:

       * host creates window, passes it to the plugin as the "parent"
         window for the plugin's GUI
	 
       * plugin creates a window, passes it to the host which
         "parents" it into one of its own toplevel windows.

the plugin/host relationship can be in-process or out-of-process,
XEmbed doesn't care.

the big problem is that at this time only GTK+ has support for
XEmbed. Qt can support it, but its not part of Qt (it lives in kdelibs
instead, as the QXEmbed widget). I doubt if any other toolkits at this
time support it.

i am trying to investigate ways of doing this without XEmbed, which is
said to be possible and was being done in Mozilla a couple of years
ago where they realized they faced the same problems.

if we avoid the goal of having the host have some control over the
plugin GUI window, then this isn't necessary, and the design i
implemented last night will work without any special support from X or
toolkits. it does require a small library with what steve has termed
"toolkit specific hacks" - its not so much that as enumeration of
supported toolkits. however, the goal of the host having some control
over the plugin GUI window seems rather desirable.

--p