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

[David Faure]

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, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5