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

David Faure faure at kde.org
Wed May 7 11:54:26 UTC 2014


On Monday 05 May 2014 11:45:22 Marco Martin wrote:
> On Monday 05 May 2014, David Faure wrote:
> > > does KSharedConfig::openConfig("confignamerc") now tries in ~/.config or
> > > in ~/.config/kde.org ? (supposing the domain is set)
> > 
> > I reverted the change for now.
> 
> ok, so i will delay any local change in plasma
> 
> > Let's discuss whether the alternative is
> > better
> 
> so, the choice if i understood correctly is basically between:
> 
> defaulting to use the domain in KSharedConfig::openConfig("confignamerc")
> that would probably be faster porting, *but* risking to break all uses of
> kdeglobals and the like,

Yes (but we can find shared config files by going through the frameworks - and 
possibly fixing the rest of the code to NOT access those files directly, after 
all if we one day switch KConfig to a different backend then direct access 
will break)

> or not use the domain in this case, *but* risks to break all openconfig of a
> filename (that is not intended to be a global one) right?

Yes.

> i don't see much painless ways..
> almost seems to call for another method like "openGlobalConfig()" or
> something like that, like the flag but even more explicit.
> would perhaps be less confusing, but a bit late to be any painless never the
> less...

The term "Global" is already overloaded twice in KConfig
(global vs local dirs, and global as in kdeglobals), let's not give it a third 
meaning (files shared between apps) :-)

This is why my suggested name for the flag was more specific, 
NoOrganizationDomain.

And we already have a number of flags, surely we don't want one method for 
each combination of flags.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5



More information about the Kde-frameworks-devel mailing list