Linux: store QSettings in a single location #129
Conversation
|
Can you note why Windows is different than the unixes? |
Done. |
|
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 |
|
Please comment this rationale in the code and/or the commit message. LGTM. |
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.
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.