Moving KFIleMetadata into KDE SC (documentation and ExtractionResult)
Albert Astals Cid
aacid at kde.org
Wed Jan 22 19:13:18 GMT 2014
El Dimecres, 22 de gener de 2014, a les 18:47:37, Vishesh Handa va escriure:
> On Wednesday 22 January 2014 13:09:58 David Edmundson wrote:
> > Add COPYING file
> > ----
> > ExtractorPluginManager::fetchExtractors seems odd to me.
> > If it can't find any plugins it searches for all plugins that start
> > the same prefix.
> > I assume it's designed so I can have a plugin with the mimetype audio/
> > that will still match the file mimetype audio/mp3
> > But this means that if I add a special new plugin with the mimetype
> > audio/mp3 the original plugin will stop running? Given you're trying
> > to build a list of all valid plugins, is that meant to happen?
> I've added the relevant documentation.
> > --
> > ExtractionResult:
> > Having setInputUrl / setInputMimetype public in a way which can be set
> > by the plugins seems wrong; personally I'd put the two in the
> > constructor.
> > --
> > We should document the list of names of properties that can be extracted.
> > Some things are in lowerCamelCase i.e "wordCount" "author" except for
> > the eviv plugin which is in the form:
> > Exif.Image.Make
> > and the odf extractor which is in the form
> > "dc:title"
> > to me it seems fairly random.
> Fixed. Added a proper property and type system.
Looks good to me. +1 to move to kdelibs.
More information about the kde-core-devel