[Kdenlive-devel] [patch] Human readable names for pixeliz0r and lenscorrection

[Dan Dennedy]

On Sun, Mar 17, 2013 at 11:55 AM, Dan Dennedy <dan at dennedy.org> wrote:
> Hey guys, it turns out we made a bad decision a long time ago about
> how MLT uses frei0r. I am thinking about making a new frei0r1 filter
> that uses numeric property names for each frei0r param. Each plugin
> would be exposed as frei0r1.<plugin.name>. You see, a Pitivi dev sent
> a patch to improve some frei0r parameter names, and I did not like
> that because it affected our API. However, then I realized our flaw. I
> will retain the existing "frei0r." for backwards compatibility and
> convenience for command line users and scripters. Any thoughts?

An alternate solution I have in my working copy is to keep the
existing MLT service names - no frei0r1. Instead, it accepts either
frei0r_param.index or frei0r_param.name as a MLT property name, but it
always/only creates the service metadata with frei0r_param.index as
the MLT property names.

> ---------- Forwarded message ----------
> From: Dan Dennedy <dan at dennedy.org>
> Date: Sun, Mar 17, 2013 at 11:45 AM
> Subject: Re: [patch] Human readable names for pixeliz0r and lenscorrection
> To: Jeff Fortin <nekohayo at gmail.com>
> Cc: Minimalistic plugin API for video effects <frei0r at lists.dyne.org>
>
>
> 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 at gmail.com> 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-+