Skip to content

Settings: Serialize enums and newtype structs #23302

@viridia

Description

@viridia

What problem does this solve or what need does it fill?

The new bevy_settings crate currently only handles regular Rust structs. However, resources in Bevy aren't limited to regular structs, but can be enums or newtype structs as well. It should be possible to declare these types as settings as well.

For example, suppose we have a setting for "color blind mode":

#[derive(Resource), SettingsGroup]
enum ColorblindMode {
    None,
    Deuteranopia,
    Protanopia,
    Tritanopia,
}

Currently such types are ignored by the settings framework. If we attempt to naively map this to TOML syntax, what we would likely get is a top-level property:

colorblind_mode = "none"

However, having top-level properties that aren't in any section is not TOML-idiomatic. We need a better solution.

What solution would you like?

The SettingsGroup decorator supports a "group" option, but this simply replaces the resource type name; what we want instead is something that adds a second name. Something like:

#[derive(Resource), SettingsGroup(key = "mode")]
enum ColorblindMode { ... }

Where key specifies the name of the property key. The name of the section is the type name, to be consistent with the behavior of SettingsGroup for other types:

[colorblind_mode]
mode = "none"

Also, like other structs, you can have a single TOML section contain properties from multiple structs:

#[derive(Resource), SettingsGroup(group = "video", key = "colorblind_mode")]
enum ColorblindMode { ... }

Assuming that there were other resources for resolution and framerate, etc., you'd get a single section like this:

[video]
colorblind_mode = "none"
resolution = 1024
framerate = "highest"

What alternative(s) have you considered?

Not supporting enums and tuple structs, instead requiring developers to use structs only.

Additional context

#23172

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-AppBevy apps and pluginsC-FeatureA new feature, making something new possibleD-ModestA "normal" level of difficulty; suitable for simple features or challenging fixesS-Ready-For-ImplementationThis issue is ready for an implementation PR. Go for it!X-UncontroversialThis work is generally agreed upon

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions