-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Settings: Serialize enums and newtype structs #23302
Copy link
Copy link
Open
Labels
A-AppBevy apps and pluginsBevy apps and pluginsC-FeatureA new feature, making something new possibleA new feature, making something new possibleD-ModestA "normal" level of difficulty; suitable for simple features or challenging fixesA "normal" level of difficulty; suitable for simple features or challenging fixesS-Ready-For-ImplementationThis issue is ready for an implementation PR. Go for it!This issue is ready for an implementation PR. Go for it!X-UncontroversialThis work is generally agreed uponThis work is generally agreed upon
Metadata
Metadata
Assignees
Labels
A-AppBevy apps and pluginsBevy apps and pluginsC-FeatureA new feature, making something new possibleA new feature, making something new possibleD-ModestA "normal" level of difficulty; suitable for simple features or challenging fixesA "normal" level of difficulty; suitable for simple features or challenging fixesS-Ready-For-ImplementationThis issue is ready for an implementation PR. Go for it!This issue is ready for an implementation PR. Go for it!X-UncontroversialThis work is generally agreed uponThis work is generally agreed upon
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