[linux-audio-dev] Knobs / widget design

Martin Habets errandir_news at mph.eclipse.co.uk
Thu Jun 10 11:34:32 UTC 2004


On Wed, Jun 09, 2004 at 07:18:57PM -0400, Dave Robillard wrote:
> On Wed, 2004-06-09 at 17:56, Arnold Krille wrote:
> > Still the question is: What toolkit to use for a 
> > standard-LAD-Gui-elements-set? Or just define the graphics and the handling 
> > and then let everyone implement it in his/her preferred toolkit? The last 
> > would be my suggestion, and maybe I am volunteering to create on for Qt...
> > 
> > Arnold
> 
> I think we've (perhaps?) finally figured out that we can't really have a
> "standard-LAD-GUI-elements-set".  It will just turn into another
> LADSPA-GUI war, nothing will get decided, and nothing will get done.

I agree.

> For example, you would like  to volunteer to create one for Qt.  Great! 
> I hate Qt - even having the abomination installed on my machine is a
> comprimise as far as I'm concerned (just to give you an idea of how some
> people feel, I'm not trying to start a flamewar here).
> 
> Some people would want it in Gtk, the Qt people would refuse..
> Some people would want it in C++, the C people would refuse..
> Some people would want it in some scriptey thing like Python, the Real
> Programmers would refuse..
> 
> etc. etc. etc.
> 
> I think at this point all we need is a mechanism for a host to say
> "plugin, show your GUI now".  (Incidentally what DSSI does as far as I
> know, which isn't very much yet).  No embedding, no standard widget set,
> no crazy event loop stuff.  Let's (gasp!) actually do something that
> will get done.  (Of course noone is stopping anyone from making an
> audio-app-gui-widget library, far from it)

>From a plugin perspective I think we would want to stay away from that
even. I would suggest just offering access to the plugin parameters via
a shared data segment (preferable with some meta-data describing the
parameters).

With this, people could write/use whatever frontend they want: command
line, GUI, socket, etc.

An no, I'm not gonna recommend a meta-data standard for the parameters :).
AFAIK there are only a few in use as we speak in audio. Any one of them
should do, and the frontend should just take what they get. Off course,
it would be nice if (in time) we could standarize on one...

> GMPI will come along eventually and make it all but a memory anyway,
> non?

I can't draw any real conclusions from the current state of GMPI.
Given that, I think it is best to use a bottum-up design approach with
multiple layers.

On the topic of personal customization I'd recommend using .Xresources
(aka .Xdefaults) in stead of .knobrc:
*knob.background:   green3
*knob.forground:    orchid
*knob.type:	    plastic
This should work for Gtk, Qt, etc.

-- 
Martin



More information about the Linux-audio-dev mailing list