Re: [linux-audio-dev] ladspa plugin GUI proposal

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

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


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:17:56 EEST