# Editor Preferences System

The editor will need a way to store user settings such as window size, graphics options, sound and music volumes and so on. These settings are typically per-user, but may also be per-project, or common to a set of related projects.

Preferences may be set explicitly (such as adjusting a music volume slider) or implicitly (like the fact that the user has already seen the tutorial and doesn't need to see it again), but in all cases are the result of user interaction.

All modern operating systems have designated locations for application preferences. For games that run in a browser, user preferences can either be saved in browser local storage, or stored on a server.

## Background Work
+ Previous discussion: https://hackmd.io/@dreamertalin/rkhljFM7R (from which portions of this document are copied).
+ Prototype: https://github.com/viridia/bevy_basic_prefs (which we may use as a starting point for further development).

## Goals

### Requirements
+ Files are to be encoded in UTF-8.
+ All files must be stored within a`.TOML` file.
+ Preferences are expected to be stored in namespaces.
+ All preferences should be exposed to Bevy plugins.
+ Every preference is modifiable within the user interface.

### Nice to Have
+ All changes made within the editor should be reflected immediately upon saving..
+ Alert the user if they are overwriting preferences that were changed on disk.
+ Layered and hierarchical preferences.
+ Preferences can be easily definable by any plugin.

### Negligible (Unnecessary)
+ Actively checking for file modifications (hot reloading).
+ Saving preferences in Binary.

## List of Preferences
Here is a defined list of necessary preferences that the editor will need at minimum.

### Object arrays
+ Workspace Layouts *(workspace_layout)*
+ **D**

## Hierarchical Structure of the Preferences
From lowest to highest priority, here is the current state of the layered preferences system. Note that this reflects future implementations that have not yet been completed.
- **Global** - All workspaces inherit their default configurations using the global preferences. This can also determine global hotkeys that are usable anywhere, regardless of workspace preferences (unless explicitly overriden).
- **Workspaces** - Workspace preferences use the global preferences by default. End users can modify them, customizing their layout, theming and hotkeys. The file is created when the user applies changes to their workspace preferences within the editor. Workspace preferences can be shared between multiple projects and are not isolated to project folders.*
- **Projects (Override)** - Project preference overrides are empty and stored within the project settings. When a project overrides a global/workspace preference, it is no longer possible to change them. In order to modify the preference, users must modify the project settings instead. There are two states that overrides can be in:
- **Inheriting** - No override is set. Users can freely change the preference. Users can use what they have set within the global/workspace preferences.
- **Modified** - When an override has been set, users can no longer change the preference without modifying the project settings. You can switch between inheriting and modified at any time without consequence.

###### *Current implementations won't reflect this behaviour until the editor is in a more complete state. For now, workspaces *will* be tied to projects. This is not the intended behaviour for the full release and will be changed in the future.

## Hypothetical
Here are some other suggested solutions, significantly more hypothetical and should be regarded more as ideas as opposed to plans.

- Perhaps we should attempt to build on [Veridia's existing reflection & resources based preferences system](https://github.com/viridia/bevy_basic_prefs), rather than building our own solution.
- Allow end users to modify the file paths of where their preferences are stored? (However, this seems more like something we should not expose to the user, if we do so).

## Open Questions
One thing to think about is what a "project" means in this case. Is it a rust crate? What if we are running on an artist's machine without rustc.