[linux-audio-dev] and just to finalize ...

[Paul Davis]

>I'd like to say: woohoo!

i suppose that if i knew this was possible 2 years ago, i would never
have written JACK. that's the upside, perhaps. should JACK exist? is
the address space isolation worth it? big questions.

>What are the arguments against stuffing the UI code in the same .so file?

what happens if you wanted a different GUI for the same plugin? well,
personally i think this is too much of an edge case - people who want
to do this can learn to recompile/relink. so i'd be fine with putting
it in the same .so file.
 
>> 2) the GUI would have to declare which toolkit it was using so that
>>    the host could ensure support for it (i.e. fire up a thread that
>>    will run the equivalent of gtk_main or QApplication::exec()) and
>>    ask the relevant toolkit thread to call the primary entry point to
>>    the GUI. how does it declare this? a well known symbol? is it a
>>    char* or a function call? is it in the LRDF entry, or the filename,
>>    or what?
>
>This can be wrapped in a non toolkit specific library, right? Cant most of
>this be handled by the plugin UI?

the library has to be (dynamically) linked against every toolkit for
which it offers support. the host uses the library to open the plugin
GUI. the host has to do something like:

     switch (plugin->toolkit_id) {
     case PLUGIN_GUI_GTK_2:
          return load_gtk2_plugin (plugin_handle);
	  
     case PLUGIN_GUI_QT3:
          retur load_qt3_plugin (plugin_handle);
     
       ...
     }

think of it was a "factory method" in OOP.
 
>> 6) [ only if we really wanted hosts to have a "real" handle on the
>>    plugin GUI window ] the library would need to contain a way to
>>    pass in an X "Window", and wrap it up as a native drawing area
>>    for each toolkit. i would prefer not to do this for now, if ever.
>
>I'm not clear on the specifics of how this all works, but the host may
>well want to swallow the plugin window(s) and max/minimise it and so on.

it appears to me this morning that the XEmbed protocol is in fact
exactly what is called for here, and will work for at least GTK+ and
Qt. i'm going to write a short demo.

--p