QSettings stored at multiple locations #121
Comments
slipher
added a commit
to slipher/updater
that referenced
this issue
Jul 13, 2024
Fixes the Linux part of Unvanquished#121. Choose the location of our settings by changing the default location for settings, rather than customizing the parameter of our settings object. This makes it so the settings added by a component we depend on end up in the same place.
slipher
added a commit
to slipher/updater
that referenced
this issue
Jul 14, 2024
Fixes the Linux part of Unvanquished#121. Choose the location of our settings by changing the default location for settings, rather than customizing the parameter of our settings object. This makes it so the settings added by a component we depend on end up in the same place.
slipher
added a commit
to slipher/updater
that referenced
this issue
Jul 16, 2024
Fixes the Linux part of Unvanquished#121. Choose the location of our settings by changing the default location for settings, rather than customizing the parameter of our settings object. This makes it so the settings added by a component we depend on end up in the same place. Some more explanation quoted from the Github thread: > I still don't understand the reasoning? Is it that the name "Unvanquished Development" is better on Windows? > With the organization name, actually Mac and Windows are the same and Linux will now be different. Previously, we chose the unvanquished/updater path to store the main settings of the updater. Some stuff was stored in an Unvanquished Development/Unvanquished Updater path by accident; I want to stop that. We need to go with the lowercase one to maintain compatibility with the previous version of the updater. But yes, the lowercase ones seem more in line with Linux stylistic conventions.
slipher
added a commit
that referenced
this issue
Jul 16, 2024
Fixes the Linux part of #121. Choose the location of our settings by changing the default location for settings, rather than customizing the parameter of our settings object. This makes it so the settings added by a component we depend on end up in the same place. Some more explanation quoted from the Github thread: > I still don't understand the reasoning? Is it that the name "Unvanquished Development" is better on Windows? > With the organization name, actually Mac and Windows are the same and Linux will now be different. Previously, we chose the unvanquished/updater path to store the main settings of the updater. Some stuff was stored in an Unvanquished Development/Unvanquished Updater path by accident; I want to stop that. We need to go with the lowercase one to maintain compatibility with the previous version of the updater. But yes, the lowercase ones seem more in line with Linux stylistic conventions.
|
#129 fixes the issue for Linux. It's still there on Windows and would be a lot harder to fix for Windows. Mac is probably not affected since it uses the default parameters when constructing QSettings (like Linux has been changed to do). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We use the
QSettingsto store some settings for the updater. But there is also some Qt support code that makes its own QSettings in a different place to store settings for "QQControlsFileDialog". We should try to make all of them be in one place.HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Unvanquished Development\Unvanquished Updaterwhile QQControlsFileDialog is atHKEY_CURRENT_USER\SOFTWARE\Unvanquished Development\Unvanquished Updater.~/.config/unvanquished/updater.conf, while QQControlsFileDialog is in~/.config/Unvanquished Development/Unvanquished Updater.conf.A potential complication is that our main settings location on Windows requires admin permissions to write. But this would only become a problem if some component used in the splash screen were to need QSettings.
The text was updated successfully, but these errors were encountered: