kconfig question

[Matthew Dawson]

On Saturday, January 23, 2016 11:54:56 AM EST David Faure wrote:
> 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.
I thought he mean Romaing\ or Local\ to be the path to AppData, where roaming 
or local changed based upon how the Windows profile was setup.  The second 
local\ I had assumed was coming from Qt, since it appeared in both.

If that was not the intent, then I apologize and agree with David.  If that is 
the case, I'll try and do some digging.  I just don't have a Windows machine 
handy I can do this on.

> 
> 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>.
I wasn't thinking the default should change, as applications would lose their 
preferences as the config files are looked for in a different location.  
Regarding library use, I agree that even allowing an app developer to change 
the default could be dangerous.  Not sure what the best way to deal with that 
is.

> 
> 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...
+1

-- 
Matthew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5584 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160123/ebb05d4c/attachment-0001.bin>