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

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.

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.