K4AboutData

[David Faure]

Hi Stephen,

as promised I had another look at the KAboutData vs K4AboutData situation,
in order to attempt to minimize the SIC.

Context: 
KCmdLineArgs uses K4AboutData rather than KAboutData: K4AboutData keeps the 
old mechanism for delayed translations (I18N_NOOP), while KAboutData is the 
one used by plugins, which can use immediate translation (i18n).

Problem:
Existing code needs a s/KAboutData/K4AboutData/ as the very very first porting 
step.

Half-solution:
KAboutData could be renamed KAboutInfo, so that K4AboutData can become 
KAboutData again.
However, for consistency this means renaming methods like setAboutData() to 
setAboutInfo(), which already creates more porting work further down the line.
And worse, there are other classes like KAboutPerson and KAboutLicense which 
still need a solution in order to not clash between the deprecated versions 
working with KLocalizedString and the new versions working with QString.

Conclusion:
I think it's a lot simpler to keep things as is, and run a very simple perl or 
sed script as the first step when porting new code. I can provide it, but I'm 
sure you wrote it already :)
Note that kde-dev-scripts/kf5 has a few porting scripts already, I can add it 
there of course.

I can see how the compiler error message might confuse people, which is 
exactly why it should really in the documented steps for porting to kf5 rather 
than letting people discover the error from gcc.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5