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, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
