Nepomuk Metadata Extractor moved to KDE Review

[Jörg Ehrichs]

Hi Albert,
thanks for your input.
I have a few questions about them though.


2012/11/5 Albert Astals Cid <aacid at kde.org>
>
> How are you handling the i18n in the lib part? It seems like you'd need a
> KCatalogLoader in there.

i18n is something I never liked about KDE, it is a big magic box to me
and i'm always glad if it works "somehow".

is it enough to call
K_CATALOG_LOADER(metadataextractor);

to make this work?
Or do I have to change anything else?

>
> Do we need to have a whole folder (sro) full of autogenerated files?
>

I had this in a README todo I totally forgot about it.
I did add this locally, but this means a simple cmake run now takes
around ~20min on a quite powerfull machine.
I'm not sure if this is a really good solution. On the other hand, i
don't have to deal with changes in the Shared Desktop Ontology
and update these generated fiels always.

What do you think? should I upload the change and live with the very
long compilation problem?

>
> metadataparameters.h is installed but does not have the export nor uses a d-
> pointer
> publicationspipe.h is installed and missing a d-pointer, same for
> nepomukpipe.h
> There are also some classes with no private date but no d-pointer either, if
> you need to expand

I've added d-pointer for all classes, except "metadataparameters.h".
i'm not really sure how to transform this struct into a class with d-pointer.

Should I add getter/setter for each function? Doesn't this make the
dpointer stuff kinde pointless, as I need to add/change the functions
everytime
I add something (like I would do with the current way)
Or is there a way to "expose" the dpointer itself in a getter, so i
can get all variables behind it?

Is there some other clever way to deal with it? The MetaDataParameter
is merly a container that is used at different places,
to hold all the information.

Kind Regards,
Joerg