Generate bindings for custom uxml components

Unity supports re-use of uxml components in other uxml components. Rosalina doesn’t generate bindings for these custom uxml components.

Pseudo-ish code for an idea about what to generate:

// CustomComponent.g.cs
public partial class CustomComponent
{
    private VisualElement _root;

    public CustomComponent(VisualElement root)
    {
        _root = root;
    }

    public Button MyButton { get; private set; }

    public void Initialize()
    {
        MyButton = (Button)_root?.Q("MyButton");
    }
}

...

// MainUIDocument.g.cs
public partial class MainUIDocument
{
    [SerializeField]
    private UIDocument _document;

    public CustomComponent MyCustomComponent { get; private set; }

    public VisualElement Root
    {
        get
        {
            return _document?.rootVisualElement;
        }
    }

    public void InitializeDocument()
    {
        MyCustomComponent = new CustomComponent((VisualElement)Root?.Q("MyCustomComponent"));
    }
}

In general, I have uxml components that will never be a top-level UI element. They will always be composed by something else, so their [SerializeField] UIDocument _document field is unnecessary.

[Eastrall]

At the moment, Rosalina supports only native types: https://github.com/Eastrall/Rosalina/blob/9ed4c726ec0badb3a31da9d53bc8c2b65bd88ac8/Editor/Scripts/Generator/UIPropertyTypes.cs#L7-L30

I believe this is a good idea to add support of custom components, let’s plan this for next releases. Thanks for the suggestion!

[Eastrall]

You are correct, the default constructor generation is a mistake. I thought that without a default constructor, Unity wouldn’t be able to instanciate the Menu document as a component on a game object. Looks like I was wrong, since I removed it and it still worked.

I’m not familiar with how the auto-generation code works, but maybe you can generate different versions of the file based on it’s usage. In your example above, when the autogeneration code gets to Menu.uxml, it’ll see that it contains a MenuItems template. Instead of generating the default MenuItems.g.cs, you could generate a MenuItems.Component.g.cs that only has a single constructor expecting a VisualElement. And when the code generation gets to MenuItems.uxml, it’ll generate the default MenuItems.g.cs, which can be used as a normal top-level ui component.

The code generation mechanism is triggered by uxml file. Which means that every uxml file is treated one by one. Thus looking for what uxml is a component wouldn’t work in that case. I tried to mix up both code generation processes because I currently don’t have any other way to identify what is a component and is not. But, once the Unity team finishes the UI Builder extension mechanism, I would be able to create a field that would allow the developer to specify what “kind” of document it is. For example, a document, a component, an extension, etc…

Another approach would be to have something more “manual” which could be integrated along with the suggestion made on issue #26 : Manual generation

By doing a right-click on the UXML file, you could :

1. Activate / Deactivate the generation process
2. Choose how to generate the UXML (document or component)

All this would be stored in the RosalinaSettings and the code generator would generate the correct code without having a UIDocument field for custom component.