kconfig question

[Boudewijn Rempt]

On Sat, 23 Jan 2016, David Faure wrote:

>
> 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 "

Hm, looks like that was a sideeffect of something else I tried, it's now in Roaming\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)

Well, it's done in a lot of places, about 160, like:

  KConfigGroup cfg =  KSharedConfig::openConfig()->group("advancedColorSelector");

or

  KConfigGroup cg(KSharedConfig::openConfig(), "");


What I want in the end is have AppData\Roaming\Krita\ where both kritarc and the user's
custom resources are saved, like brushes and so on. I'm fine with patching kconfig for
windows for that, though.

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

Well, those are resources, aren't they? Not config files. But I confuse myself all the time, too, with those two.

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

Yes... But given that I need to build kconfig on windows myself anyway, I guess I can just patch that. In the
beginning I was just wondering wether this was the right behaviour.

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org