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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] and just to finalize ...
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Tue Nov 18 2003 - 16:39:25 EET


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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Nov 18 2003 - 16:38:40 EET