[gst-devel] G_PARAM_FLAGS mode & addition.

[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?

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

GST_PARAM_EDITABLE and GST_PARAM_CONTROLLABLE are mutual exclusive,
controlable implies editable.

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).

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.

Stefan