[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: Default location of the settings file on windows when using KXmlGuiWindow/KMainWindow
From:       Alexander Semke <alexander.semke () web ! de>
Date:       2017-12-12 21:18:52
Message-ID: a02b5915-773d-003f-17d1-3e4031d47d2f () web ! de
[Download RAW message or body]


On 12.12.2017 13:13, Kåre Särs wrote:
> On måndag 11 december 2017 kl. 21:55:23 EET Albert Astals Cid wrote:
>> El dijous, 7 de desembre de 2017, a les 22:13:21 CET, Alexander Semke va
>>
>> escriure:
>>> Hi all,
>>>
>>> https://bugs.kde.org/show_bug.cgi?id=387626
>>> we've got this problem reported and I don't see how to easily fix this.
>>> LabPlot's MainWindow inherits from KXmlGuiWindow. When saving the auto
>>> settings in KMainWindow, KSharedConfig::openConfig() is used which uses
>>> QStandardPaths::GenericConfigLocation for the location:
>>> https://api.kde.org/frameworks/kconfig/html/classKSharedConfig.html#a32820
>>> 86 49f2e3f0ee895c9b11aa82205
>>>
>>> According to the problem description in this ticket, I assume this is a
>>> valid request since it makes a lot of sense to me, we have to use
>>> QStandardPaths::AppDataLocation for the location of the config file. Do
>>> I need to set here KMainWindow::setAutoSettings() with a KConfig having
>>> the proper name and location? I'd actually expect this to be done by the
>>> underlying framework(s)...
>>>
>>> We read the settings in many places via KSharedConfig::openConfig()
>>> which also defaults to the same rc file under
>>> QStandardPaths::GenericConfigLocation. For all our custom and
>>> application specific settings we can of course provide AppDataLocation
>>> explicitely but this also looks to me like not the most optimal solution
>>> since we'd need to touch the code at many places. How is this handled in
>>> other KF5-applications? Can somebody share some best practices here?
>> You may try the kde windows list if noone answers here.
> Actually I think kde-frameworks-devel would be a better place to take this up.
> (CC:ing)
>
> One problem is that we have have used GenericConfigLocation long before
> AppDataLocation was introduced and there would be backwards compatibility
> problems if we directly would just switch to AppDataLocation.
How about checking first whether the rc-file already exists in 
GenericConfigLocation? If it already exists, use it. If not, create a 
new one in AppDataLocation.
With this we shouldn't run into backward compatibility issues and should 
be fine (i.e. using the roaming folder) with the new default location 
for new users.


-- 
Alexander

[prev in list] [next in list] [prev in thread] [next in thread]