kconfig question

[Ralf Habacker]

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 at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160128/376e6eed/attachment.html>