On Sunday 08 November 2015 19:02:38 René J.V. Bertin wrote: > On Sunday November 08 2015 18:25:25 David Faure wrote: > > 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?
Not really. I do exactly that to run KF5 apps in a KDE4 desktop here. And I did the same during the kde2-kde3 and kde3-kde4 transitions ;) 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 even automated when entering a directory. For instance with the chpwd() zsh function at the bottom of https://techbase.kde.org/Getting_Started/Increased_Productivity_in_KDE4_with_Scripts 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 ;) > > 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? Dunno, I thought we were talking about virtual desktops. > 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. Sounds to me like you could make sonnet use IniFormat on all platforms. > > > (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." Ah, good find. > 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 :) 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. Sounds like you need to check all apps ;) 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 -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel