GNOME Bugzilla – Bug 696513
geometrictransform: add angle property variants with degrees instead of radians as unit
Last modified: 2018-11-03 13:15:01 UTC
perceived: a mouse over hint which says "radians" and to rotate approximately 90° I actually needed help by a calculator expected: able to enter angles in degrees comment: I am a human and not that much into fractions of PI, srsly. thanks
In second thought it is quite easy to divide 3.14159 by 2 but... I thought I was sitting in front of a computer which knows how to compute
Hi, that would be something that should be fixed in GStreamer's "rotate" filter. The relevant code would probably be geometrictransform/gstrotate.c in gst-plugins-bad.
Oh I think differently. I think this is a user interface problem. The user interface problem is, that a user has to read and write radians instead of degrees. My idea of GStreamer filters in general and gst-plugins-bad specifically is, that it is a library and developers can code with that and radians is just fine in code. Because of that I think user interface problems aren't business of GStreamer filters. I think the pitivi is responsible for doing this simple conversion. But I am unsure cause I neither found the string "radians" nor "degree" in pitivi source of the now. Well, don't understand things I don't understand.
I'm not sure, it's a bit awkward to let the application handle this, but it might be the best way. Not sure we want to remove the existing properties, so that just leaves adding new properties. Which doesn't hurt I guess.
Well, I don't see why humans should have to deal with radians in the first place - degrees are what's natural to mortals... and thus I think the gstreamer plugin should deal with degrees instead, if GStreamer maintainers agree. Adding special-case hacks in downstream applications is counterproductive and generally against our "upstream first" approach, especially given the fact that the UIs for effects in pitivi are all automatically and dynamically generated from whatever GStreamer gives us.
(In reply to comment #5) Ah, I see. augmenting this automatic generation with special cases like this is some maintenance. I agree that this should be minimized. Related to your first sentence I think that radians is the mathematically more useful representation of angles. Degrees aren't natural in fact, they are just common :) Natural would be a drawing of a circle and a circle segment ;) I think of an analogy: How is it done with translations? Is GStreamer providing perfectly translated property names and stuff? I didn't looked into that and I suppose it does not. So somewhere needs to be a translation component which turns "radians" into "Bogenmaß" and "radián" and "弧度". So how do you do translation? Cause this would be a component near to the thing which could turn radians into degrees or whatever.
Stefan has an interface in buzztard/buzztrax that allows to annotate properties with metadata, IIRC one of those annotations was the "unit" of the property. So for the angle this could just say "radians" and then pitivi and others would know what it is and could convert to whatever they want to show the user. Also I'm not sure about the more natural argument, you can easily argue for absurd things with that (feet are more intuitive than meters :P ) and also mathematicians might very well disagree on radians vs. degrees here :)
> Stefan has an interface in buzztard/buzztrax that allows to annotate properties > with metadata, IIRC one of those annotations was the "unit" of the property. David also mentioned something he had in ew-encoder which is similar: ds: We don't really have good ways of expressing user interface details as part of properties slomo: ds: yes, ensonic is the person to talk to about this :) ds: I've done a bit of this in GSS, in order to get GObject properties to show up in the HTML UI decently __tim: ds, I think those param spec hints would already go a long way __tim: https://bugzilla.gnome.org/show_bug.cgi?id=522205 __tim: so at least you can flag which ones to expose/hide in a UI __tim: (but I suspect you want something more expressive?) ds: one thing that hasn't flowed from ew-encoder to GSS yet is a structure that gets attached to every property (either by the object implementation or the app) that describes how to show it in the UI ds: also how to save it to a config file ds: I've been mostly happy with this so far ensonic: The problem is that one can easily over enginier it, (e.g. expressing contraints) ds: just add javascript! ensonic: maybe we can have a sensitive signal, like notify to signal that properties are ignored or not ds: one of my worries is that what goes into a particular element depends on implementation details, not any kind of user interaction design ds: so in pitivi, you expose all the pattern generators in videotestsrc as one pattern generator with lots of functions ds: a questionable UX design ensonic: ds, yep, some of the parameters in videotestsrc are specific to the function ds: not only that. "I want a black slug" is a pretty typical operation in a video editor ds: "I want a pattern generator with a solid color with a background color of black" is technically the same, but UX is uselessly different. ensonic: ds, something like this could be done via presets ds: true ensonic: not with the ones we have ensonic: imho the gnome video effect where heading that way, gst-launch snippet + some parameters exposed Apologies if we're drifting a bit off-topic now :)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/90.