Subject: Re: [linux-audio-dev] ladspa plugin GUI proposal
From: David Benson (daveb_AT_idealab.com)
Date: Wed May 24 2000 - 18:43:27 EEST
> 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.
I agree that forcing plugins to use any given set
of widgets is unfortunate. Nonetheless I see
xml as giving us the ultimate toolkit independance
so I am trying to merge ideas.
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.
GtkWidget-derived classes can be loaded as plugins.
I assume similar holds true of other serious toolkits.
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>
Of course, there'd still have to be a bunch of little
details resolved: how to get control port mappings, etc.
And the plugin that used this could include the relevant
gtk+ or kde or whatever widget-plugins.
(Of course, this might lead to an ugly fracturing of
kde or gtk+ plugins, but i think that the best solution
there is going to socket/plug type arrangements, bleh)
Does this kind of reasoning lead to sufficient flexibility,
do you think? (i know it's full of little problems...)
- dave
This archive was generated by hypermail 2b28 : Wed May 24 2000 - 19:17:56 EEST