ltoscano added a comment.
One thing for sure: the code should be moved back to the constructor, and not dynamically at each call of desktopFileName(), or it would be a behavioral change. (Or at least it should be probably cached if we get an agreement in breaking this). And regarding this: In https://phabricator.kde.org/D5405#101570, @kossebau wrote: > Having slept over this one night, I still think that this change should be not the way to go to fix the seen issues. > > The actual problem is bad usage in application code, usually due to lack of knowledge what is needed. > The documented API of KAboutData, especially AboutData::setDesktopFileName() <https://api.kde.org/frameworks/kcoreaddons/html/classKAboutData.html#a112d2fc20c31e7847995930e030cc67b>, is very explicite what needs to be done and when. This patch would change this behaviour and runs a chance to break things for application code which relies on the documented behaviour. > Changing this behaviour to help application code whose authors never bothered to get things only means screwing over those application developers who did the effort to read up in the API dox and write proper code. I don't see why removing the homepage from the calculation of the default value of the desktop file when the org domain is specified breaks the current behavior. It does not change the fact that program writers should set the domain, but if you set it, it should be the relevant source (see my points above). Sane default; yes, you can call setDesktopFileName explicitly, but is it really needed? REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D5405 To: stikonas, mpyne, kossebau, aacid, ltoscano Cc: mak, plasma-devel, kde-frameworks-devel, #frameworks, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, eliasp, sebas, apol
