GNOME Bugzilla – Bug 522205
define more GstParamspec flags
Last modified: 2018-05-04 08:44:02 UTC
We need to define all GST_PARAM_ flags in one place to provide a GST_PARAM_USER_SHIFT. Therefore GST_PARAM_CONTROLLABLE should be moved (gstparamspec.h has been choosen). The attached patch also adds initial proposals for further flags.
Created attachment 107209 [details] [review] move flags and define new flags
Created attachment 107210 [details] irc discussion for reference
Why should CONTROLLABLE only be a hint? I think all properties with this flag should be controllable using GstController, ie. it should be a hint about what's actually implemented and supported. The description makes it sound like that's only a maybe. PRESETABLE => PRESETTABLE: makes sense to me. USER_SHIFT: seems ok to me too. Not sure about the USER_EDITABLE. There is much overlap between the three, but that's not really a problem IMO. The EXCLUDE_FROM_UI_HINT thing seems to make the most sense to me, but I haven't thought too much about it. We don't really need USER_EDITABLE urgently for anything in particular, do we? It's more a 'nice to have and figure out while we're talking about the other two', right?
thanks for quick feedback. None of the flags enforces anything. Its just about describing some aspects of the properties. CONTROLLABLE describes temporal aspect - flagged properties make sense to be changed over time. one way to to that is GstController, other way would e.g. be UI. GstController does a safety check by looking at the flag. USER_EDITABLE vs. EXCLUDE_FROM_UI_HINT (or INTERNAL) a negative form is indeed more effective. At least we can just apply this to most baseclasses and thats it then. I would like to start using this in buzztard. Right now I have a blacklist with stuff like name/qos/sync/...
> CONTROLLABLE describes temporal aspect - flagged properties make sense to be > changed over time. one way to to that is GstController, other way would e.g. be > UI. GstController does a safety check by looking at the flag. Are you saying that if a property is CONTROLLABLE but the element does not use/support GstController you wouldn't consider this a bug?
If any object-property of an element is marked as CONTROLLABLE the elements needs to do gst_object_sync_values(). Otheriwse the GstController won't work. What I was emphasizing is the view on the element-interface from the application. In a media player one plugs elements that are needed to decode a clip. If there are multiple choise we use the rank. In a contents creation application (like pitivi or buzztard) the application needs to figure e.g. what elements can be used are a source for a timeline and what as effects and so on. Elements with controllable properties are good candidates. Then those apps need to generate a ui. Looking at the controllable flag provides a useful hint to divide properties into dynamic and static ones, where one would not offer the static ones for modification when the pipeline is playing (e.g. location of filesrc). CONTROLLABLE is just a flag. If its used the application can rely on the fact that the GstController can be attached to those properties, but if an application like cheese just wants to offer three sliders for realtime control thats fine too.
While we have some agreement about CONTROLLABLE and PRESETTABLE, what to do with USER_EDITABLE. This could also be added as a negative form : UI_SKIP. An application that generates UI for elements would benefit from hints to aid hiding stuff that does not make sense to be configured via ui. First one can apply some heuristics: * hide parameters with pointer or object types (hard to edit from ui in a generic way) * hide construct/constructonly or !writable properties The remeaining onews would benefit from the hint. Where would I apply it in core: GObject: name GstBaseSink: sync, qos, async GstBaseTransform: qos FakeSink: <all> FakeSrc: <all> FdSrc: fd FdSink: fd FileSink: buffer-mode, buffer-size FileSrc: fd, mmapsize, touch, use-mmap, sequential Identity: <all> MultiQueue: <none> Queue: <none> Tee: <none> We could probably lower the amount of propertes that need the hint by using CONSTRUCT or CONSTRUCT_ONLY more often (filesrc).
Committed the CONTROLABLE and USER_SHIFT part.
Created attachment 109283 [details] [review] add new flags Please comment on these. One thing to decide is wheter we want positive or negative forms.
Created attachment 132578 [details] [review] updated patch Updated patch for recent changes in gstparamspec.h. Note that I changed the numbers, including moving one to G_PARAM_USE_SHIFT + 0 to fill in empty space.
Btw, shouldn't it be _PRESETTABLE rather than _PRESETABLE?
According to com/index.php?lang=en_GB&word1=presetable&word2=presettable its a slight win for "presetable". Any idea why there should be a second "t"?
Settable is "settable", so I imagine presettable should be the same.
ping?
Created attachment 151671 [details] [review] updated patch Fixed the name according comment #11. Still needs a decission about the FIXME:s in the comments. To recap, we have GST_PARAM_CONTROLLABLE: its controlable in PLAYING - in a UI one can map it to a timetime - it can be saved to a preset GST_PARAM_USER_EDITABLE: show param in a ui - opaque properties are not user-editable - construct_only|read-only properties are not user-editable - see comment #7 (the list there is about a negative form) GST_PARAM_NOT_PRESETTABLE: hint that this should be stored in a preset - opaque properties are not presettable - construct_only|read-only properties are not user-editable so there is some overlap. So, we could drop EDITABLE and define EDITABLE = PRESETTABLE - CONTROLLABLE The reasoning is that if you do presets, you show all those options in a UI, some part of those options are marked as CONTROLLABLE, the remainder are properties that can be editied, but more as a setting (not changing it over time).
Ping? This would be a good thing to figure out and move on.
Comment on attachment 151671 [details] [review] updated patch Should get rid of all the FIXME comments at least ;)
Stefan, what should happen here? I'm not sure of the meaning of USER_EDITABLE, if there is a property it is meant to be edited by the user, no?
(In reply to comment #18) > Stefan, what should happen here? I'm not sure of the meaning of USER_EDITABLE, > if there is a property it is meant to be edited by the user, no? No, e.g. the 'parent' property would not have USER_EDITABLE. Maybe it is more efficient to have a negative form - GST_PARAM_NOT_USER_EDITABLE. (In reply to comment #17) > (From update of attachment 151671 [details] [review]) > Should get rid of all the FIXME comments at least ;) I'd love to.
Is this still something you're interested in?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!