[mostly OS X]: KDEHOME vs. ~/.kde best practices, *rc files and related questions

René J.V. Bertin rjvbertin at gmail.com
Mon Nov 9 12:36:33 UTC 2015


On Sunday November 08 2015 21:58:21 David Faure wrote:

>Not really. I do exactly that to run KF5 apps in a KDE4 desktop here.

Et te, Brutus? :)

>It's just a matter of writing your export statements in a file that you source
>before running a kf5 app (from a terminal). The sourcing of the env can be

Yeah. Not really what I had in mind, but you're right, it's feasible.

>But anyway the whole point is to let KF5 be more integrated with the rest
>of the system, while you're trying to make it less so ;)

Being more integrated is a worthy goal, but IMHO not so much if it comes at the detriment of flexibility, for the (borderline) cases where that integration is not desired. (And I wouldn't bet anything that you've been able to foresee all such cases, as well as assess whether they will indeed remain borderline cases ;) )

>> Is it also possible that some autotest from KF5-solid messes up the Network-Manager state?
>
>Dunno, I thought we were talking about virtual desktops.

Rather about side-effects of running autotests, the number of virtual desktops only being an example.
BTW, even if you're guess was right I don't see why one would expect an autotest to alter a desktop setting persistently (i.e. not restore it).

>Sounds to me like you could make sonnet use IniFormat on all platforms.

I'm hoping that's what my patch does. If you're saying I could submit it for review ... I guess I could do that :)

>We call setOrganizationDomain("kde.org") already, in many places (*), but it sounds like you found an app where that's missing.
>(*) this is either done when main() calls KAboutData::setApplicationData (given that KAboutData defaults to domain=="kde.org")
>or it might call qApp->setOrganizationDomain() directly.

Should the organisation domain be set to "kde.org" or to "org", given that there is also QSettings::setOrganisationName()?
Besides, the QSettings documentation says
"If you want to specify a different domain name, call QCoreApplication::setOrganizationDomain(), QCoreApplication::setOrganizationName(), and QCoreApplication::setApplicationName() in your main() function and then use the default QSettings constructor"

which I read as "use QSettings::QSettings() and not any of the other constructors"; that's also the only way to be sure QSettings::setDefaultFormat() is actually used.

>Sounds like you need to check all apps ;)

I'm not sure I care enough to start searching all apps other than on a case-by-case basis when I catch one being naughty ;)

>
>This made me search for kde.com in our source code and it seems some people got this wrong -- but that's not the bug you found :-)
>http://lxr.kde.org/search?_filestring=&_string=%22kde.com%22

No, it's either my analysis above, or the simple fact that the autotests do not call setOrganizationDomain(), which would be forgivable if it didn't lead to the creation of a Sonnet settings file with an inappropriate domain.

R.


More information about the Kde-frameworks-devel mailing list