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?
---------- Forwarded message ---------- From: Dan Dennedy <d...@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 >