Re: Default location of the settings file on windows when using KXmlGuiWindow/KMainWindow
- Date: Tue, 12 Dec 2017 14:13:26 +0200
- From: Kåre Särs <kare.sars@xxxxxx>
- Subject: Re: Default location of the settings file on windows when using KXmlGuiWindow/KMainWindow
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
> > 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.
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.
> > Thanks and Regards,
> > Alexander