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
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
