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