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, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel