On Fri, Jul 8, 2011 at 6:17 AM, Brian Matherly <pez4br...@yahoo.com> wrote: > Hi Dan, > > >>On Thu, Jul 7, 2011 at 9:42 PM, Dan Dennedy <d...@dennedy.org> wrote: >>> On Wed, Jul 6, 2011 at 8:53 PM, Brian Matherly <pez4br...@yahoo.com> wrote: >>>> Dan, >>>> >>>> I've been working on adding to the service metadata. Basically, I'm >>>> working my way through "services.txt" and transposing the information into >>>> the .yml files. I must admit, I'm not testing most properties for accuracy. >>>> >>>> I'm about half way through services.txt, and I thought I would pass along >>>> what I have so far before I get too far along. Let me know if there is >>>> anything I should be doing differently. >>> >>> Thank you, Brian! You are definitely on the right track. I went ahead >>> and committed what you have because it is at least mostly correct, >>> just as helpful as anything else, and one step closer to eliminating >>> services.txt. I will continue to review tonight and revise as needed. >> >>Take a look at my last commit that contains my revisions for some >>conventions. Besides functional property corrections: >>- Only capitalize first word of title >>- Usage of '>' vs '|' for text blocks. '|' is for pref-formatted text >>and '>' collapses whitespace. '>' can contain multiple paragraphs: use >>a blank line between them containing indent-number of space >>characters. > > > I can easily adopt your suggested conventions moving forward. > > > A couple of questions: > * Should we include "in" and "out" point properties for all services? Right > now it is inconsistent (some include it, some don't). I expect that all > services have in/out point properties (except possibly device based producers > and consumers). >
Ya know, I have been wondering the same myself. These properties are generic and already documented with Doxygen. I would really appreciate a cleanup patch that removes from all existing yml: in, out, length, resource, and aspect_ratio. > * Would you consider renaming " /src/modules/gtk2/filter_rescale.c" to > "filter_gtkrescale.c"? Then it would match the name it is registered with in > gtk2/factory.c. That way, when I create filter_gtkrescale.yml, the name will > match the file it applies to. I can supply a patch if you want. > I have kind of been intentionally avoiding metadata for normalization filters since they are not intended to be used directly. See src/modules/core/loader.ini for the list of normalization filters. These get applied to each producer automatically. However, there are some exceptions like crop that are used in two ways: one as the image processor and another to simply apply properties (as an alternative to using, e.g., set.crop.top on the producer). > * Is there a release imminent that it would be worth getting these all done > before? If so, what's the deadline? Yes, there is. I want to make a release this Sunday. But don't sweat it. There are no applications really dependent upon this at the moment for its functionality. -- +-DRD-+ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
