Fwd: [kconfig] src/core: Store app config file in ~/.config/<domain>/<app>rc

[David Faure]

On Monday 05 May 2014 08:29:07 Martin Gräßlin wrote:
> On Monday 05 May 2014 08:17:49 David Faure wrote:
> > On Monday 05 May 2014 07:25:37 Martin Gräßlin wrote:
> > > On Sunday 04 May 2014 23:53:40 David Faure wrote:
> > > > Hello,
> > > > 
> > > > please note this change in KConfig.
> > > > 
> > > > I would recommend making sure your applications call
> > > > app.setOrganizationDomain("kde.org") so that the config files go into
> > > > the
> > > > right subdir right now. Otherwise you'll face migration issues later
> > > > when
> > > > setting that.
> > > 
> > > How does that affect setting configuration from a kcm? E.g. if loaded
> > > through systemsettings one could assume that setOrganizationDomain is
> > > set
> > > to "kde.org" which could break any kcm needing another organization
> > > domain.
> > > Or if a KCM sets this to foo.bar than any kcm not resetting to kde.org
> > > would break, wouldn't it?
> > 
> > I doubt KCMs use KSharedConfig::openConfig() or KConfig() without
> > arguments. That would lead to "kcmshell5rc" or "systemsettingsrc" right
> > now.
> > Instead they surely name the config file they want to edit.
> > 
> > If that config file happens to be for a specific application (rather than
> > shared), then the KCM will need to open e.g. "kde.org/konquerorrc" instead
> > of "konquerorrc", indeed.
> 
> Yes, that's what I mean. E.g. in KWin our kcms do:
> KSharedConfig::openConfig("kwin");
> 
> while in KWin it might be possible that we do:
> KSharedConfig::openConfig();
> 
> (though I think most use KSharedConfig::openConfig())
> 
> which would result in breakage if we forget to adjust one.
> 
> Thus it looks to me that we need to verify each and every KConfig and
> KSharedConfig::openConfig call and also kcfg files, right?

Right.

I just thought about an alternative:

KConfig defaults to "<organizationdomain>/" for all config files including the 
named ones, but gains a flag "NoOrganizationDomain" which we'd have to use for 
files that are shared between applications, such as kdeglobals, kdebugrc, 
trashrc, servicetype_profilerc, kbookmarkrc, emaildefaults, kwalletrc, etc. 
Anything that is opened by a framework or other general-purpose libraries 
needs that flag, otherwise apps with a different org domain wouldn't find 
them.
At best, for cleanliness, libs can hardcode a prefix such as kde.org, but they 
can't rely on the value of organizationDomain.

Maybe this way around is less work indeed. I'm not sure. The risk for 
undetected breakages is higher (since we'd only notice it when running an app 
with a different org domain). Kate will end up being the perfect test app for 
this, with its kate-editor.org domain :-)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140505/a3d8f189/attachment.sig>