Review Request 117275: Deprecate the catalog name stuff from KAboutData

Alex Merry alex.merry at kde.org
Tue Apr 1 10:09:35 UTC 2014


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117275/
-----------------------------------------------------------

(Updated April 1, 2014, 10:09 a.m.)


Review request for KDE Frameworks, David Faure, Kevin Ottens, and Michael Pyne.


Changes
-------

Make the constructor require fewer arguments, not more.


Repository: kcoreaddons


Description (updated)
-------

This is another thing on the "if only we'd spotted it before beta1" list.  I went with not allowing any optional arguments to the constructor, to encourage users of the class to use setters, which makes for more readable code.  I deliberated giving it just one argument, but in the end went with the formerly-required arguments.

The organizationDomain is not automatically set from the home page with this new usage style, as that only happened in the constructor and not in the setter.  It could be set if the organizationDomain has not been explicitly set.  However, the organizationDomain is not passed to QCoreApplication as I assumed it would be - it that intentional?


Deprecate the catalog name stuff from KAboutData

This is pretty useless - the translation catalog has to be set before
KAboutData is constructed in order to translate its arguments.


Diffs (updated)
-----

  src/lib/kaboutdata.h cff1e3f67e33657fdd265a82166ef2a04cbcc3d1 
  src/lib/kaboutdata.cpp ce64a13aaa89bb4bc077f05e5f8e175d6a441ead 

Diff: https://git.reviewboard.kde.org/r/117275/diff/


Testing
-------

Builds, tests pass.


Thanks,

Alex Merry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140401/3904b964/attachment.html>


More information about the Kde-frameworks-devel mailing list