Generate bindings for custom uxml components
See original GitHub issueUnity 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.
Issue Analytics
- State:
- Created a month ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
Manual: Bind with UXML and C# script
This example demonstrates how to create a binding and set the binding path with UXML, and call the Bind() method with a C#...
Read more >Create a bindable custom control
This example creates a custom control bound to a property with the double data type. You can adapt this example to bind to...
Read more >Feature Request - Custom UXML Attributes
Hello, I would like to propose a way to define my own Attributes for VisualElements that I have little to no control of...
Read more >Extending the Unity Editor with custom tools using UI Toolkit
Like building your own UI tools? Here we go step by step with the UI Builder to quickly create an Inspector for real-time...
Read more >Untitled
A GameObject's functionality is defined by the Components attached to it. ... See in Glossary; UXML; SerializedObject data binding; Create the custom ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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!
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.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 :
All this would be stored in the
RosalinaSettings
and the code generator would generate the correct code without having aUIDocument
field for custom component.