On Sun, Mar 17, 2013 at 11:55 AM, Dan Dennedy <d...@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 <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 <nekoh...@gmail.com> > Cc: Minimalistic plugin API for video effects <fre...@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 <nekoh...@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-+ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Kdenlive-devel mailing list Kdenlive-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
