GNOME Bugzilla – Bug 626462
Add the possibility to add a category to an element
Last modified: 2016-11-11 21:30:02 UTC
In the case of effects in particular, it would be nice to have the possibility to define the effect categories directly in the element. For example, videobalance is in the 'Colors' category, videorate in 'Noise', aspectratiocrop in 'Geometry'... It is not possible to specify it for now. As slomo said on IRC: http://bugzilla.gnome.org/show_bug.cgi?id=396774 'should get it fixed and then define more element class metadata, including something for your use case'
whats wrong with gstElementDetails.klass ?
The gstElementDetails.klass is to define the type of element, it is not something we would show to the end user at the difference of the category which would actually be showed to him directly.
I am not totally convinced. This would need some good definition to make sure its been used correctly. What kind of semantics do you have in mind. Should it be a list of tags like the gstElementDetails.klass field (strings, separated by '/') or a single value. Do you want to define an ontology somewhere and use only defined values?
I am actually thinking about categories as the ones I defined in this file http://github.com/thiblahute/Pitivi/tree/effects/pitivi/effects.py This should probably directly be included in Gstreamer so any application can use it (And all the effects actually have categorisation). I think it should be a list of tag similar to gstElementDetails.klass actually What do you think is wrong with this idea?
I am just worried about the overlap. E.g. "Analysis" is already in the gstElementDetails.klass. Slightly unrelated, did you meant to classify "videorate" as "Noise"? One argument for having a separate metadata-item would be that gstElementDetails.klass is not translated, but this one would be. But then we probably need to make it a list/array and not a composed string.
What is the problem about the overlap? I don't think the gstElementDetails.klass could be used instead of the list of categories, the goal is very different. You are right, it should be a list of string and for sure it must be translatable to be usefull.
gstElementDetails::klass can't be translatable though, it's used in code to detect decoders, etc.
So, what to do here?
Maybe apps needs to handle that them self. Otherwise we need to ensure that all kind of apps are happy with the ontology we pick. Thibault, could you write down how you would define both; gstElementDetails::klass and gstElementDetails::categories. Both are a list of tags. Right now we only miss that ::klass is translatable. Also, should these categories be user-editable or defined in the element code?
Do we still want to do this? If we want, we can also define a new metadata-key for this. As a prerequisite it would be nice to make a list of elements we want to categorize and a list of proposed categories.
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!