D5439: API dox: more info about KAboutData's orgDomain/desktopFileName properties

Luigi Toscano noreply at phabricator.kde.org
Fri Apr 14 18:24:49 UTC 2017


ltoscano added inline comments.

INLINE COMMENTS

> kossebau wrote in kaboutdata.cpp:689
> Why would you also add a comment here? Would you think the comments at the places which should be changed are not enough?
> The KF6 TODO proposes to change the behaviour to follow the idea of https://phabricator.kde.org/D5405.
> "set it to domain + component name" sounds as you propose to store a auto-generated value in the desktopFileName variable. But that would need an extra flag to know if the value is auto-generated and thus needs to be updated if the sources for the value change or if the value has been explicitely set by the user, so should not be auto-updated.
> 
> But I propose to leave the actual implementation more to whoever changes it at KF6 times, as it is hard to predict what other requirements/views will be at that time :)

I think that any extra unneeded step is only prone to produce issues.
In 90% of the cases (and probably more, like basically all stuff on kde.org), the desktop file name is org domain + component. No need to do it again and again. A flag is a minimal price to pay, if needed. Maybe it's not even needed, because you can compute it on the fly (if not set, return org domain + component, if both set).
So yes, I'd like a reminder here.
At least
// KF6: evaluate if desktopFileName can return org domain + component if not explicitly set.

REPOSITORY
  R244 KCoreAddons

REVISION DETAIL
  https://phabricator.kde.org/D5439

To: kossebau, #frameworks, stikonas, mpyne, aacid, ltoscano
Cc: dfaure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170414/19234865/attachment-0001.html>


More information about the Kde-frameworks-devel mailing list