Subject: Re: [linux-audio-dev] ladspa plugin GUI proposal
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed May 24 2000 - 19:04:37 EEST
>I think it is clear that it would be nice
>if plugins could define their own widget
>types and so on. For example, a "power spectrum" widget
>needs pretty specific drawing semantics.
This one can all be easily handled with the "set-of-pixmaps" approach.
A harder example is an EQ curve editor.
>GtkWidget-derived classes can be loaded as plugins.
>I assume similar holds true of other serious toolkits.
I don't know exactly what you mean by this. If you mean that we can
load object code that implements a specific widget, sure, I'm sure
they can all do this.
>So... what if the xml allowed:
>
> <native-widget-plugin>
> <class>PowerSpectrumDisplay</class>
> <arg_name>arg_value</arg_name> <!--- maps onto gtk-arguments
> --- or whatever system is
> --- being used --->
> </native-widget-plugin>
The problem with this is that the gtk-arguments system is not, to my
knowledge, replicated in other kits, including Gtk--. As a result, the
XML handler would have to contain handlers for every possible
widget. If we're going to do this, I'd favor fixing libglade to
include an audio-friendly set of widgets, and just using that.
>Does this kind of reasoning lead to sufficient flexibility,
>do you think? (i know it's full of little problems...)
If libglade was complete and/or easily extensible, then yes, I can see
the virtues in this approach - thats why I used it in Quasimodo.
But, I can't see this being used to construct plugin GUI's that even
come close to the beautiful creations VST/TDM users are used to. Thats
OK, except that I'd like plugins to be able to do this if the host
would let them.
--p
This archive was generated by hypermail 2b28 : Wed May 24 2000 - 19:44:35 EEST