[gst-devel] G_PARAM_FLAGS mode & addition.
ensonic at hora-obscura.de
Tue Jan 30 10:44:37 CET 2007
in gstreamer/libs/gst/controller/gstcontroller.h we have:
* 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
* 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
#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.
More information about the gstreamer-devel