kconfig question

[David Faure]

On Monday 18 January 2016 10:28:18 Matthew Dawson wrote:
> On Monday, January 18, 2016 8:53:22 AM EST Boudewijn Rempt wrote:
> > On Sun, 17 Jan 2016, Matthew Dawson wrote:
> > > It appears this is the desired behaviour.  On most platforms,
> > > GenericConfigLocation and ConfigLocation are the same things, except
> > > Windows. According to Qt's history, ConfigLocation was supposed to act
> > > like GenericConfigLocation, but a mistake was made and
> > > GenericConfigLocation was introduced to fix that without breaking
> > > existing applications.  See commit
> > > 44d48862c0ff4b67a76734deae5e76f926a77bce .
> > > 
> > > KConfig was then changed to use GenericConfigLocation as well, see commit
> > > b3487a0684fa464ada0cd3407e96d0406345a42a in kdelibs (this happened before
> > > the split).  On all platforms except Windows, that is how KConfig has all
> > > behaved. Even in KDE4, config files were often put in the same directory,
> > > just not a standard directory shared by the platform.
> > > 
> > > Based on the commit history, I'd say it makes sense.  Anything else would
> > > yield platform inconsistent behaviour, which is more likely to confuse
> > > people. If ConfigLocation wasn't inconsistent across platforms, that
> > > would be a different story.
> > 
> > Hm, but I don't think that having kritarc in a directory called "local" on
> > every platform is important: the important thing is to have it in the
> > location that's "normal" on those platforms.
> Taking a quick look at my Win7 machine suggests that the path Qt uses for 
> GenericConfigLocation is a mix of .config/.local/.cache on *nix.  According to 
> Qt's documents, no other system uses a local/ folder for 
> GenericConfigLocation.  So that seems "normal".

Not sure this answers Boud's question, since he *is* seeing "Local" on Windows.
He said: "I noticed that krita on windows wrote its kritarc to Roaming\local\ or Local\local "

According to the QStandardPaths documentation, it is expected to see
something like "C:/Users/<USER>/AppData/Local" in the paths for GenericConfigLocation

The the lowercase "local" after that puzzles me. I wonder where that comes from,
it's not anywhere in the QStandardPaths code for Windows, nor KConfig AFAICS.

Boud, how is KConfig called exactly?
  (I don't mean "it's called KConfig" ;-) I mean what does the code using it, look like?
  I think this needs some debugging to find out where this "local" string comes from)

> > > Regardless, changing the default behaviour now is a no go, as that would
> > > break everyone's setup.  However, I wouldn't be opposed to a method to
> > > allow KConfig to easily store config files in an application appropriate
> > > folder.  It couldn't break existing applications though.  I also don't
> > > think most things should need it anyways, since most applications only
> > > have one config file. Something like akonadi (which already uses a
> > > subfolder in my .config) makes sense, and I could see it making sense for
> > > Krita.  Maybe some way to use AppConfigLocation?  We'd have to be careful
> > > with that though, since it's> 
> > > >=5.5.
> > 
> > I'm fine with 5.5 as a minimum for my own purposes :-). I just don't want to
> > have to change a couple of hundred locations to explicitly pass
> > AppConfigLocation.
> I meant that a patch for KConfig would have to be careful, since KConfig can't 
> depend on 5.5 (yet).  I think just using the defaults will be ok, if you have 
> only one config file.  If you have more, then I'd agree that AppConfigLocation 
> seems better.

Don't forget that KConfig is also used by libraries, not just by applications.
Let's pick a random example: KIO, which stores the KFileWidget mode (icon or list) that the user prefers.
Right now this is global, it affects all applications. If you make KConfig use AppConfigLocation
by default, then suddenly this setting is per application. Maybe no big deal for this particular one,
but imagine having to select your spellcheck dictionaries in all apps or <insert a ton more global settings here>.

In general, I don't like AppConfigLocation, we've been bitten by "appdata" too much in kde4 times, same issue:
some code starts as app code, it uses such an app-specific location type, then it's moved to a library,
and that breaks sharing data between apps (example: kmail identities, initially in kmail, then one day
moved to a library --> definitely want the identities to be shared, not per app). But I guess that's my
"library developer" point of view, I can understand that application developers don't want to hardcode
"krita/kritarc" everywhere...

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