Web lists-archives.com

Re: Default location of the settings file on windows when using KXmlGuiWindow/KMainWindow





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