Refactored user/project settings #96
Merged
Conversation
This file contains 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
* Created SOArchitecturePreferences to enable easy editing of user preferences and project settings from editor windows. On 2018 and earlier, these will be shown in the editor preferences window while on 2019 and later these will be split between the project settings and user preferences windows. The project settings exposed on these windows are still saved as part of a SOArchitecture_Settings scriptable asset. * Refactored user settings from SOArchitecture_Settings into editor preferences. User preferences for enabling gizmos/debug will now be an editor pref and not be a checked-in setting on SOArchitecture_Settings instance. This allows developers on the same project to have different settings.
* Moved the SOArchitecture_Settings instance out of the library folder as this would prevent users who downloaded this library as a package from modifying their settings (assets in the packages folder are locked from overwriting) as well as at risk of being clobbered when updating the package as the new package version would overwrite any force local changes.
|
Hey, I realize you're probably busy; just bumping this as a reminder. |
Fix for bool pref always set/returned as true
|
This is cool, I had no idea you could do this 👍 |
|
I changed the feature a bit. Instead of having a pre-defined settings asset in the resources folder, the asset will generate one for you when needed. It also no longer uses the resources to locate the project settings, instead opting to query the asset database. Also added warnings if more than one settings asset is present in the project. |
|
Amazing PR as always, I especially appreciate the in-depth explanations :) |
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.
Summary
I recently pulled this library as a package into a new project and had a hard time tracking down the settings to disable the debug feature. I realized that some of the existing settings for debugging or gizmos are checked in as part of the Settings scriptable asset which means one developer's preferences could potentially clobber another developer's preferences.
To make it easier to expose these settings to the user in a standard way as well as to separate user preferences off of the checked-in Settings asset, I've created a new preference class that allows easier access for developers to these settings regardless of the Settings asset location and separates the Gizmo/Debug configuration to use Editor Prefs instead.
A developer can now modify their user preferences at the menu item Unity=>Preferences and navigate to the SOArchitecture section as shown below. These are now saved as Editor Prefs and can differ per developer.
A developer can correspondingly modify the project-wide settings by opening the menu item **Edit=>Project Settings" and navigate to the SOArchitecture section as shown below.
Using the new search fields for the editor windows (in I believe 2019 and later), you can also search for the SOArchitecture library in either the Preferences and Project Settings window to make it easier to find.
One final related change is that I moved the SOArchitecture_Settings instance currently checked in outside of the SO Architecture folder so it would not be included for developers who download this as a package. Including this would potentially prevent them from modifying the contents as well
(usually package contents are protected), but definitely prevents their settings from being overwritten when a new package version is downloaded as package contents are considered disposable when changing versions and are blown away completely during that process. Any customized settings would go away in that circumstance. Its better that this asset is created in the developers Assets/Resources folder initially (just how the Singleton instance creation currently works), but this would be prevented by including this asset in the package contents.
If you have any questions or concerns please let me know on the PR!