Subject: Re: [linux-audio-dev] ladspa plugin GUI proposal
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Wed May 24 2000 - 18:21:27 EEST
my thoughts:
I want a flexible system, where even toolkits that do
not exist yet should work.
How about the following:
the plugin specifies an
Editor function similar to VST.
we provide an easy to use lib which allows the host
to launch the various toolkit-threads.
(for now it would be the gtk thread and the Qt thread).
Assume the plugin's GUI is written in GTK.
The plugin's Editor function needs a standard way to
inform the host's toolkit ( the gtk-thread), that this widget
wants to be added.
Since the host uses threads, the gtk-thread sees the
.so code loaded by the host's main thread.
At this point the gtk-thread simply adds the widget by
calling the appropriate functions.
And if this does not work, there is a 2nd way which
will work almost certainly.
Instead of threads use separare processes.
(eg the gtk-process and the Qt-process).
split the plugin into 2 .so files
one .so for DSP work, the other .so file for the
GUI editor.
eg. filter.so and filtergui.so (written in gtk)
The gtk-process will load the filtergui.so code
and execute it happily.
If the main host has to communicate with the
editors, do this via IPC shared mem
or using the shared memory provided by threads.
With one of the two scemes above,
we need 1 thread/process per toolkit (but that is a
non issue from a performance POV),
but we have the great advantage that we can
load as many toolkits as we want.
as for VSTGui:
with my proposal, VSTGui will simple be be
an additional handler (process/thread)
just like Qt and Gtk.
That means you can write your VSTGui process
using Gtk , Qt, raw X etc.
summary:
- main host runs it's preffered GUI toolkit (gtk,Qt,Motif etc)
- all plugins are free to use what kind of toolkit they want
- there will be a library which allows the host to manage
the gui-handlers with an easy to use API.
- the GUI handlers execute the GUI portion of each plugins
which are coded using the same GUI toolkit
- if the host needs to communicate with plugin GUI elements
it does so using thread shared memory or IPC shmem in the
case when gui-handlers are separate processes.
- the plugin can even provide it's custom GUI thread without
utilizing the plugin handlers (because they do not support that
toolkit or for other special reasons).
comments ?
Benno.
On Wed, 24 May 2000, Paul Barton-Davis wrote:
> Oops. I forgot a rather important thing:
>
> >The problem is that whatever other library (Motif, Qt, etc) opened the
> >connection almost certainly set up its own event loop to deal with X events,
> >and Very Bad Things will happen if you open up your own connection and
> >set up your own event loop.
>
> So, my scheme is not going to work, but neither is any other than
> assumes sharing a single X server connection.
>
> Since several toolkits are not capable of handling multiple X server
> connections at the same time, it is also not possible to simply have
> each plugin initialize the toolkit (which typically sets up a new
> connection), since this will trample over toolkit-global variables
> used by other plugins that use the same toolkit.
>
> So, back to the drawing board. Either we have to provide the toolkit
> layer (like the vstGUI library), or we specify the host's chosen
> toolkit and have the plugin be required to use it. This last one is
> pretty disgusting.
>
> Thoughts ?
>
> --p
This archive was generated by hypermail 2b28 : Wed May 24 2000 - 20:23:05 EEST