Let's also include the mailing list. You wrote a lot, and I do not
want to touch on every point, so I am going to top post.

I am wrong about the usage of frei0r parameter names as the API. The
API uses a parameter index. It is just MLT's bridge that was
contributed a long time ago that makes the param name meaningful and
effectively like an API. You see, the contributor chose to not require
scripts and command-line users to use an index for setting things and
instead chose to use the parameter name as the way to specify
parameter values. I guess it comes down to a matter of API style:
whether you like position-oriented parameters or named parameters. So,
your change may only negatively affect MLT, and you asked the wrong
person to commit on your behalf. ;-)

So, now I have to think about the impact of trying to change MLT's
usage of frei0r or whether to simply stick my head in the sand.

On Sun, Mar 17, 2013 at 8:48 AM, Jeff Fortin <nekohayo@???> wrote:
> Le samedi 16 mars 2013 à 12:18 -0700, Dan Dennedy a écrit :
>
>> I wonder if in gstreamer you have something like param info where you
>> can provide some mapping from identifier to a more appropriate label?
>
>
> My very limited understanding of C and the stuff in
> http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst/frei0r/
> tells me that GStreamer does no mapping or mangling of properties
> presented by frei0r, excepted color or position properties, as I found
> out in https://bugzilla.gnome.org/show_bug.cgi?id=695884 (if you have
> thoughts on what Tim said about color properties, by the way, your
> opinion is much more valuable than mine on this matter :)
>
> GStreamer provides a property name (ex: white-noise-sensitivity), a
> human-readable "nickname" for that property, and a description. The
> nickname is what I set out to fix in the case of pixeliz0r. Or do you
> mean to tell me that frei0r has no such distinction? Then I'm confused,
> how come GStreamer manages to have one without having a hardcoded
> mapping dictionary?
>
>
>
>> I am sorry, but I am going to reject this and patches like it because
>> you are changing the interface, which breaks existing projects and
>> scripts that use these parameters.
>
> Wait... you mean the human-readable names *are* the API in frei0r?!
> And frei0r never ever dares to break API even for a single filter?
>
> If so, I don't quite understand why there are human-readable names then,
> instead of computer-readable names that are then clearly meant as API?
>
>
>
>> For a similar reason, MLT's service
>> metadata system has both identifier and title attributes for a
>> parameter so the id can stay the same while changing the label.
>
> Huh, it looks like MLT does what Frei0r should have been doing?
> Doesn't that sound a bit upside-down? :)
>
>
>
>> Otherwise, why not just create a bunch of custom UIs over frei0r for
>> Pitivi? It is python so it might not be that much code. Or you can
>> make a bunch of dictionaries to map things. As a side benefit, it is
>> more likely that code will be translated over fei0r's.
>
> Because with Pitivi, we believe in an "upstream first" approach (working
> with upstreams rather than accumulating hacks downstream).
>
> If I understood you correctly, every software project that wants to use
> frei0r effects has to manually maintain a mapping of everything - a
> mapping that may/will break because it's not actually upstream - and
> every project has to have its own set of people translating the strings
> that could have been translated only once (if you'd like a French
> translator for frei0r, I'll be glad to help)?
> That approach strikes me as rather inefficient!
>
> For the case of Pitivi, on "why not use a bunch of custom UIs over
> frei0r filters"? Well the way I see it, in the end there is no point in
> having code that autogenerates UIs if you're going to make and maintain
> a hand-crafted override UI for each and every single effect, no? That
> means creating and connecting UIs for over a hundred filters, and every
> project out there NIH'ing that work every time. Hundreds of UIs created
> and maintained all over the place. To me that sounds like a terrible
> waste :(
>
> Of course, there are some effects for which there clearly is a need for
> a UI override (like the very nice color correction wheels in shotcut),
> but in 9 cases out of 10 (even as I've seen in how kdenlive presents
> things) it's just a bunch of numeric values (or checkboxes, or
> comboboxes) that would be fine with a dynamically generated UI.
>
> Some other nice things about not hand-crafting the UI for every single
> effect out there are:
> - You can detect problems upstream, use that as a testing platform, etc.
> - You could have keyframeable properties without manually connecting
> everything everywhere
> - You stay lean and avoid basically duplicating API of frei0r (or other
> libraries) into your application.
>
>
> This is all food for thought and, at the end of the day, I'm not sure
> any of my humble arguments here will convince you... but please take the
> time to think it over ;)
>
> Best regards
>



--
+-DRD-+