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".
> > > 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. -- Matthew
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
