Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
From: est_AT_hyperreal.org
Date: pe elo 27 1999 - 16:55:22 EDT
Guenter Geiger discourseth:
> est_AT_hyperreal.org writes:
> > > It's possible to set these things whenever you like.
> > > The plugin programmer can decide which properties can be changed,
> > > and which not. That's what the virtual verify function is all about.
> >
> > Hmm..I'm wondering if there should be a harder distinction between
> > properties and parameters re mutability.
>
> The difference is that properties have to be set for a plugin.
> Properties are the way how we can determine if the plugin fits for the
> application or not.
>
> Parameters are values that can be changed during plugin operation.
..and *some* properties, depending on what the verify() function says,
am I correct? A lot of this comes back to my questions re
sampling-rate and blocksizes. Perhaps properties *should* be
immutable throughout. If a plugin is flexible about sampling-rate
and/or blocksizes, it can use a don't-care value for those properties.
I'd prefer to have those things modified through the setparam()
methods anyhow since they may entail modifying other private data.
> > > > * The popup method should probably be expanded to a vector of generic
> > > > gui methods.
> > > >
> > >
> > > As few as possible, but right, we may need more .....
> >
> > Maybe config_dialog(), show(), hide() and a gui type string?
> >
>
> Hide could be done by the plugin itself,
Not if the app wants to do it.
> show is the same as popup.
Yes.
> I'm not sure what config dialog means, but if its an additional
> dialog this could be started form the plugin's GUI as well.
>
> I think we should keep any GUI stuff out of the API as good
> as possible.
OK. Here's a simplifying suggestion. Two fields: 1) a gui type
string and 2) an opaque gui data pointer.
Eric
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST