Nepomuk Metadata Extractor moved to KDE Review

[Jörg Ehrichs]

>> 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".
>
> I guess you did not automagically learn how to code in C++, you read about it,
> asked people and then learnt. The same applies to i18n handling, it's just a
> big magic box because you never cared to learn
>

Thats true. Its just that everytime I read through techbase and though
I fully understood this issue I seem to have missed something.
Well at the end to get these kind of errors kde review exist, over
time I should have deald with all the usual problems and should
be ok with it.


>>
>> > 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.
>
> But you only need that on the first compile, no?
>

Yes this would be a one time thing, although it needs an additional
compile switch to deactivate this generation
for the second run at the moment, as the cmake file to generate this
is not away of any caching mechanism and I
have currently no clue how to add it.

>> 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?
>
> We don't keep moc files in the repo, keeping them would be faster compile
> times, but autogenerated files in a repo always seemed a bad idea to me.
>

Thats true and if this class generation was as quick as the moc file
generation I would never have asked to get around it
At the end, most people will not compile this from source but rather
use distro packages and thus this is a rather small problem

I will push my changes tomorrow.

>
> You are also missing the export (if that class is suposed to be used
> externally, that i guess it is since you are installing it)
>
>> Should I add getter/setter for each function?
>
> Yes
>
>> 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)
>
> And? Adding functions is fine SC and BC wise, read
> http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ on why
> d-pointers are important.
>

I might have had a kinda wrong understanding about the d-pointer issue than.
I'll change the struct into a full class with appropriate
getter/setter and the d-pointer.

Thanks for the hints and help.

Cheers
Joerg