Re: [linux-audio-dev] LADPSA GUI

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

Subject: Re: [linux-audio-dev] LADPSA GUI
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed May 24 2000 - 18:58:36 EEST


>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.

I think its fine for a host to completely ignore the plugin's wishes
regarding a GUI. But if the host is willing to let the plugin do its
own thing (and many will be), then the plugin should be free to do
whatever it likes. At least, this seems like the ideal to me.

>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).

Fully agreed.

>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.

libglade is good, but its not trivial to add new widgets to it.

>This also makes plugin GUI construction relatively easy (in fact one could
>probably modify glade to create a graphical plugin GUI generator).

Yep, if it contained the right widgets. But it doesn't right now.

> - 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).

Well, plugins MUST manipulate the widget, so a workaround is an
absolute necessity.

> - Hosts need code to turn a description into widgets, making host
> construction more complicated. This may be mitigated by creating
> libraries which do this.

This is pretty easy. Quasimodo has a single, fairly small file that
converts the XML descriptions of its module GUI's into real stuff.

> - Plugins would be restricted to whatever widget types are defined in
> the standard, and would not be able to create their own.

This is OK, as long as the widget types are wide-ranging enough. I am
also assuming that because of your aesthetic concerns, the widgets
would not include the previously mentioned "set of pixmaps" type.

--p


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

This archive was generated by hypermail 2b28 : Wed May 24 2000 - 19:42:35 EEST