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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
