Re: [linux-audio-dev] and just to finalize ...
Paul Davis wrote: what a night (paul simon on the famous AG concert in central park) 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. What about reparenting the window like the window manager does? I must confess: I don't know anything about programming this but have heard about the concept. AFAIK, any window can be absorbed by a container -- but I don't know what this really and programmatically means. So it's just an idea ... Uwe -- voiceINTERconnect www.voiceinterconnect.de ... smart speech applications from germany
Re: [linux-audio-dev] and just to finalize ...
I'd like to say: woohoo! On Tue, Nov 18, 2003 at 02:23:05 -0500, Paul Davis wrote: what would all this mean for LADSPA? 1) there would need to be a way to associate plugins+GUIs since we probably don't want them in the same object. - could be done using LRDF or a dir search path combined with the plugin ID. I vote for the latter, otherwise the fully qualified GUI path would have to be in the metadata, which seems a bit odd. What are the arguments against stuffing the UI code 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? 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. - Steve
Re: [linux-audio-dev] and just to finalize ...
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. What about reparenting the window like the window manager does? I must confess: I don't know anything about programming this but have heard about the concept. AFAIK, any window can be absorbed by a container -- but I don't know what this really and programmatically means. So it's just an idea ... the problem is getting the GUI toolkit to use an externally created window to parent one of its own. i wouldn't want to rely on XEMBED for this, and there is probably no need to. i know that GDK has gdk_window_new_foreign(), which does 50% of the work. don't know about Qt, but i will check. --p
Re: [linux-audio-dev] and just to finalize ...
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
Re: [linux-audio-dev] and just to finalize ...
On Tue, Nov 18, 2003 at 09:22:13 -0500, Paul Davis wrote: 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. In that case its a good thing. Having spoken to people who've worked with the windows version of rewire, the address space isolation is very important. If there was an expectation (or requirement) for nice, author provided UIs for plugins, do you think there would be so many for linux now? 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. People who want to do this can define a service discovery mechanism (service discovery is my least favourite problem at the moment). They may want it to be network transparent, or platform neutral or something. 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: Ugh, this is looking less good. 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. Yes, from what I remember XEmbed is good for this kind of stuff, if only GTK and QT atr supported that would be a pain, but maybe worth it - Steve
Re: [linux-audio-dev] and just to finalize ...
Tuesday 18 November 2003 15.22 skrev 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. As others have also noted, adress isolation is god sent. Whatever you do, unless jack crashes, almost nothing can bring your application down (a mild overstatement perhaps *). This is a _major_ feature. I also think that jack apps should be easier to design and program as opposed to plugin-centric solutions. The boundaries are dictated by the operating system, not by the plugin-architecture. In my mind jack ought to have much better long-term viability than an in-proc plugin-system. Today you can probably wring out more precious clock cycles from an in-proc system since the overhead isn't as big. But in a few years (or already now!) the overhead for this is easily traded for the added benefits. /Robert * Jack does add a few critera of it's own, can you say ZOMBIE ? ;) But this is a necessity with an in-proc system also.
Re: [linux-audio-dev] and just to finalize ...
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. As others have also noted, adress isolation is god sent. Whatever you do, chiming in, address isolation is great. gdam forks processes for mp3 decoding... if mpg123 crashes, that one song ends early. with in-client mpglib a crash would take down the whole app. for anyone performing live, in front of audiences, stability and reliablity are of utmost importance. -geoff
