Background

See #1437

Feature

This enables use cases like:

#[export]
#[var(get = get_vertical_alignment, set = set_vertical_alignment)]
vertical_alignment: PhantomVar<godot::global::VerticalAlignment>;

Key Changes

• Modify:

  In godot-core/src/registry/property/phantom_var.rs

  pub struct PhantomVar<T: GodotConvert + Var>(PhantomData<T>);

This makes the requirements for PhantomVar more lenient, because GodotType is a metaphor for GodotConvert. For existing supported types where T: GodotType and Via = T, behavior remains the same.

• Add

  In godot-codegen/src/generator/enums.rs

  impl crate::registry::property::Var for #name {
      fn get_property(&self) -> Self::Via{
          <Self as #engine_trait>::ord(*self)
      }
      
      #var_trait_set_property
      
      fn var_hint() -> crate::meta::PropertyHintInfo{
          crate::meta::PropertyHintInfo{
              hint: #property_hint,
              hint_string: #enum_hint_string.into(),
          }
      }
  }
  
  impl crate::registry::property::Export for #name {}

Concern

Clearly, not all enumerations will be edited as fields in the inspector. However, this PR extensively implements Var and Export for godot enums. Is it acceptable to treat all engine enums as "exportable as properties" by default, given that it's purely additive and only used when the user opts into exporting such fields?

Additionally, I've provided a make_enum_hint_string function:

/// Returns the hint string for the given enum.
///
/// Separate with commas, and remove the `<ENUM_NAME>_` prefix (if possible). 
/// e.g.: "Left,Center,Right,Fill"
fn make_enum_hint_string(enum_: &Enum) -> String {
    let upper_cast_enum_name = enum_.godot_name.to_shouty_snake_case() + "_";
    enum_.enumerators
         .iter()
         .map(|enumerator| {
             enumerator.godot_name
                       .clone()
                       .trim_start_matches(upper_cast_enum_name.as_str())
                       .to_pascal_case()
         })
         .collect::<Vec<String>>()
         .join(",")
}

It works fairly well, with one exception: for EularOrder, users might prefer to see values ​​like XYZ rather than Xyz. Unfortunately, I cannot distinguish this through extension_api.json.

During my research of the Godot source code, I found this line:

ADD_PROPERTY(PropertyInfo(Variant::INT, "vertical_alignment", PROPERTY_HINT_ENUM, "Top,Center,Bottom,Fill"), "set_vertical_alignment", "get_vertical_alignment");

This means that Godot itself does not have a method to convert enum values ​​to hint strings, it's entirely "manually" maintained in every component that uses enum types.

This PR can be interpreted as an "overstepping" of authority, adding extra behavior to gdext that doesn't exist in Godot, but the user experience might be more comfortable than developing components on native Godot.

But is this allowed?

Thanks for considering this!