Am 28.01.2016 um 09:48 schrieb David Faure:
> On Wednesday 27 January 2016 10:32:50 Boudewijn Rempt wrote:
>> 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.
> Sounds to me like Patrick's pending patch to add configurable paths in
> QStandardPaths using qt.conf
> would work exactly right for this. Your windows installer for krita would
> install a qt.conf where
> GenericConfigLocation = [...]\AppData\Roaming\Krita.
>From the patch I do not see how it resolves relative pathes which is
very important on Windows.
In a similar patch I wrote recently for testing
https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32:Qt55/mingw32-libqt5-qtbase/0001-Add-QStandardPaths-support-for-qt.conf.patch?expand=1
I used QLibraryInfo::location(PrefixPath) as base.
Ralf
>
>
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
