Subject: [linux-audio-dev] LADPSA GUI
From: Karl JH Millar (kmillar_AT_MIT.EDU)
Date: Wed May 24 2000 - 18:06:41 EEST
I've been thinking about these GUI issues somewhat.
There is a conflict between plugins being able to control how they look/feel
and the look/feel of the host. Personally, I think that the look/feel of the
host should take priority, and we want to work to give the plugin as much
flexibility as possible within that. I certainly don't want to have to try to
mix sound with 23 differently shaped buttons, dials, faders etc on my screen.
I'd rather have just one, even if it means I have to miss out on a little
chrome.
In particular, this implies that either we standardise on a toolkit or rely
on the host to draw the plugin.
The only practical way to standardise on a toolkit in a linux system is to
make our own API. This is necessary both as there are too many toolkits out
there, and also as audio plugins tend to want controls not provided by any
of the widget sets in common usage (eg dials and faders).
If instead we rely on the host to draw the plugin, then we need a way to
request how the plugin should look. This can be done at a range of levels,
ranging from just supplying the information already in the ladspa API, to
something more like the XML descriptions used by libglade, which would give
the plugin almost complete control over how it is displayed.
This latter method strikes me as the much better option. It is toolkit
independant, and if well constructed allows the host to ensure that
all the plugins have a consistent look and feel, while allowing the plugin
plenty of leeway in layout. It makes it simple for hosts to capture user input
and it also removes the burden of dealing with multi-threading issues away
from the plugin and into the host, where I believe it belongs.
This also makes plugin GUI construction relatively easy (in fact one could
probably modify glade to create a graphical plugin GUI generator).
The disadvantages of such a system are:
- Plugins may not be able to manipulate the widget. This is sometimes
useful, and is a potentially serious limitation (although we should
be able to work around this problem in most cases).
- Plugin designers may have less control over the look of their plugin
(less chrome, same layout and functionality)
- Hosts need code to turn a description into widgets, making host
construction more complicated. This may be mitigated by creating
libraries which do this.
- Plugins would be restricted to whatever widget types are defined in
the standard, and would not be able to create their own.
Karl.
This archive was generated by hypermail 2b28 : Wed May 24 2000 - 18:44:49 EEST