[gst-devel] G_PARAM_FLAGS mode & addition.

[René Stadler]

Am Dienstag, den 30.01.2007, 10:44 +0100 schrieb ensonic:
> hi,
> 
> in gstreamer/libs/gst/controller/gstcontroller.h we have:
> /**
>  * GST_PARAM_CONTROLLABLE:
>  *
>  * Use this flag on GstElement properties you wish to be (eventually) handled
>  * by a GstController.
>  * TODO: needs to go to gstelemnt.h (to avoid clashes on G_PARAM_USER_SHIFT)
>  */
> #define    GST_PARAM_CONTROLLABLE    (1 << (G_PARAM_USER_SHIFT + 1))
> 
> I would like to move this to gstelemnt.h now. Anyone against that?

Not me at least, FWIW.

> By the means of the GST_PARAM_CONTROLLABLE apps can detect dynamic
> parameters and also use that to generate meaningful UIs. What I would like
> to add is
> 
> /**
>  * GST_PARAM_EDITABLE:
>  *
>  * Use this flag on GstElement properties that are user editable (can appear
>  * in a UI as an option).
>  */
> #define    GST_PARAM_EDITABLE    (1 << (G_PARAM_USER_SHIFT + 2))
> 
> Some examples (my opinion):
> name, sync, qos: this is stuff that the application handles.
> buffer-time, latency-time : something a user could use to configure a plugin

I must say that this distinction seems arbitrary.  One could argue that
"sync" belongs to the user visible case sometimes, while "buffer-time"
should be hidden from the user in some contexts.  It seems hard to draw
a line anywhere.

> GST_PARAM_EDITABLE and GST_PARAM_CONTROLLABLE are mutual exclusive,
> controlable implies editable.

My feeling is that this might limit the potential use of the controller
system.  As it is, it's a clever extension that allows one to set
property values in the stream time domain.  I don't see why that would
imply "user editability" (whatever that means exactly).  Treating these
concepts as orthogonal should make things easier.

> There is still something that breaks the picture: trigger parameters. I
> don't know if there is an analogy in video, but in audio these are
> parameters like 'note' or percussion triggers. They have a value, they are
> changeable at runtime, but still one would not want to have them in a
> preset nor in a settings window (one does not *set* them).

My guess is that there needs to be a way to indicate that a controllable
property recommends a particular interpolating mode.  "Trigger
parameters" would then recommend the trigger interpolator (or even
disallow other interpolating modes if they don't make sense).

> Adding another flag seems waste to me. From the functional point of view,
> it would be possible to misuse the mutual nature of GST_PARAM_EDITABLE and
> GST_PARAM_CONTROLLABLE and:
> #define GST_PARAM_TRIGGER (3 << (G_PARAM_USER_SHIFT + 1))
> 
> Of course there are many hint that one can think of. I am working on
> designing an interface that bundles UI Hints and that will attach metadata
> as qdata to GParamSpecs. I still would see the before mentioned flags as
> flags, as that allows to quickly filter.

I can't see how the flag(s) allow for filtering more quickly than
querying via an interface.

That said, I think adding a new param flag for this is wrong.  All of
the existing flags (including the added controllable flag) describe
technical capabilities of the parameter.  Meta informative hints like
"expose this in user-configurable contexts" that are to be interpreted
on a voluntary basis don't seem to belong there.

-- 
Regards,
  René Stadler