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:
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
What problem does this solve or what need does it fill?
The new
bevy_settingscrate 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":
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:
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
SettingsGroupdecorator 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:Where
keyspecifies the name of the property key. The name of the section is the type name, to be consistent with the behavior ofSettingsGroupfor other types:Also, like other structs, you can have a single TOML section contain properties from multiple structs:
Assuming that there were other resources for resolution and framerate, etc., you'd get a single section like this:
What alternative(s) have you considered?
Not supporting enums and tuple structs, instead requiring developers to use structs only.
Additional context
#23172