On Sunday November 08 2015 18:25:25 David Faure wrote: > Don't even think about it.
What, I'm not allowed to scare myself? :) > But you can of course export a different value for > XDG_CONFIG_HOME or XDG_DATA_HOME. A bit difficult to do that only for KF5 applications, eh? Except maybe through a qputenv from a KConfig initialisation routine, but that could lead to even weirder situations when a KF5 application spawns a non KF5 app ;) > I bet the KF5-based autotest talks to the running kde4-kwin, which itself > modifies > files under ~/.kde. Ah, yes, that could make sense. Is it also possible that some autotest from KF5-solid messes up the Network-Manager state? > > So then where would the com.kde.*.plist files come from? Applications (and > > frameworks, like Sonnet) using QSettings instead of KConfig? Do those APIs > > both > > write to *rc files on Linux? > > QSettings seems to be able to write to *.plist indeed. And Qt ships a settingseditor among the examples that can edit both native and .ini files . It lacks the ability to open files from the commandline ATM, but I'll probably patch that in at some point, if/when justified. > > 99% of KF5 applications use KConfig. > QSettings is used by Qt code itself, and by some Qt-based apps (non KF5). > So it's quite out of scope for KF5 to do anything about this. A number of autotests use QSettings, but Sonnet also uses it, as do policy-gen and kconfig_compiler. Those latter two use QSettings::IniFormat so there's no issue there, but Sonnet doesn't specify the format to be used. In my set-up with the activate QStandardPaths patch, it makes sense to patch the relevant lines from Sonnet to make it use IniFormat too; I'm not sure what the best approach would be there. I'd still find it preferable myself to have all config files in the same location, be it under ~/.config or somewhere else. > > (btw: seriously, COM.kde.* ??) > > I really have no idea where this comes from, we set "kde.org" as domain > everywhere. > I think you should dig further into these plist files to find out what code > could possibly > write them. I don't have enough details above to find out. I did. From the "Platform Limitations" section in the QSettings documentation: "On OS X and iOS, the CFPreferences API used by QSettings expects Internet domain names rather than organization names. To provide a uniform API, QSettings derives a fake domain name from the organization name (unless the organization name already is a domain name, e.g. OpenOffice.org). The algorithm appends ".com" to the company name and replaces spaces and other illegal characters with hyphens." It may be possible to get around that by invoking just QCoreApplication::setOrganizationDomain() in an appropriate location, but I haven't tested that. The whole issue goes away when using QSettings::IniFormat :) René _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
