Repository navigation
Conversation
The program previously stored user data (user setting JSON, bug reports,
screenshots, ...) at a single location: the current working directory on
Windows/Linux, or the user application data folder on macOS.
Add a new "Data Storage" section at the top of the Global Settings panel
with two dropdown menus, each with two options ("User app" / "Local"):
- User Data & Bug Reports Location: where the user setting JSON file and
bug (error) reports are saved.
- Screenshots Location: where screenshots are saved.
When the new settings are not in the setting JSON file yet, the program
defaults to the previous platform behavior: local on Windows and Linux,
user app folder on macOS.
Implementation:
- Filesystem: new application_user_data_path() per OS (Windows:
%APPDATA%/<name>, macOS: ~/Library/Application Support/<name>,
Linux: $XDG_DATA_HOME or ~/.local/share/<name>) and a
last_write_time() wrapper.
- GlobalAutoPaths: new UserDataStorageLocation enum and per-category
storage location state; SETTINGS_PATH/PROGRAM_SETTING_JSON_PATH/
ERROR_PATH/error report paths follow the user data location, and
SCREENSHOTS_PATH follows the screenshots location. All other paths
(debug dumps, user files, downloaded resources, ML) keep the
platform default base.
- Startup: DETECT_SETTINGS_STORAGE_LOCATION() picks the storage location
holding the newest setting JSON file (platform default if neither
exists or on a tie), so a choice made in a previous session is honored
when reading the settings.
- GlobalSettings: the two new EnumDropdownOption values are persisted
under the keys USER_DATA_STORAGE / SCREENSHOTS_STORAGE, and keep the
GlobalAutoPaths state in sync on load and on change.
- Error reports now use absolute paths (fixes the CWD-relative sent/
unsent folders on macOS).
- PersistentSettings::write() creates the setting folder if missing.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The program stores user data (user setting JSON, bug reports, screenshots, ...) at a single fixed location: the current working directory on Windows/Linux, or the user application data folder on macOS. Each has a drawback: local storage is good when running multiple program installs for multiple Switches, while the user app folder survives program updates.
This PR adds UI in the Global Settings panel for the user to control this.
UI (Global Settings panel, new "Data Storage" section at the top)
Each is a dropdown with two options: User app (the OS user application data folder, e.g.
%APPDATA%/<name>on Windows,~/Library/Application Support/<name>on macOS,~/.local/share/<name>on Linux) and Local (the folder the program runs from; on macOS, the folder that hosts the app).Default behavior
When these new settings are not in the setting JSON file yet, the program keeps the current platform behavior: local on Windows and Linux, user app folder on macOS. (Linux previously had no user-app-path behavior; it now defaults to local, same as before.)
How it works
GlobalAutoPathsgains aUserDataStorageLocationenum plus per-category location state.SETTINGS_PATH(),PROGRAM_SETTING_JSON_PATH(),ERROR_PATH(), and the error-report folders now follow the "user data" location;SCREENSHOTS_PATH()follows the "screenshots" location. All other paths (debug dumps, user files, log file, downloaded resources, ML data) keep the platform-default base.DETECT_SETTINGS_STORAGE_LOCATION()(called inMain.cppbefore the settings are read) checks both candidate setting JSON files and reads from the one that exists; if both exist it uses the most recently modified one, and if neither exists it uses the platform default. This way a choice made in a previous session is honored when reading the settings.USER_DATA_STORAGE/SCREENSHOTS_STORAGEand keep theGlobalAutoPathsstate in sync (on load and on change); switching location while running creates the folders at the new location so data can be saved there immediately.Misc
PersistentSettings::write()creates the setting folder if it is missing.Testing
GlobalAutoPathsstorage-location/detection logic was exercised with a standalone harness built from the realGlobalAutoPaths.cpp+Common/Cpp/Filesystemsources (all cases passed: neither file present, one file present, both present with different mtimes, runtime location switch).EnumDropdownOption<UserDataStorageLocation>values (default, slug load, to_json, unknown slug ignored) was verified against the real options framework.Please review the per-OS path choices (
Filesystem_Windows.h/Filesystem_Mac.h/Filesystem_Linux.h) in particular.