General feedback on things I found when playing a bit with UIElements

Hello, there is no need to tag individual UI team members as we have a process to monitor this channel

Before we look into each individual piece of feedback, Can you confirm you are using 2019.1 ?

 

@N3uRo : Let me try to respond to most your questions:

Both issues you mention in the window creator seem valid. I created bug tickets to track them.

Don't hesitate to file bugs directly using Help->Report a bug...

You can use the style attribute this way:

<ui:Label name="my-label" text="" style="background-color:blue;/>

or link to an external uss, which currently needs to be in your resources folder:

<UXML xmlns:ui="UnityEngine.UIElements">

    <ui:VisualElement name="content">

        <Style path="Styles/MyStyleSheet"/>

    </ui:VisualElement>

</UXML>   

You can use display:none in your uss, or in c#:

myVisualElement.style.display=DisplayStyle.None;

Agreed.

These are valid concerns. We are currently looking into ways to make bindings more powerful and more easily extensible, both for the editor and in the future runtime version.

As for syntax highlighting and autocomplete, you can have it with uxml files this way:
In the project pane, right-click and select "Update UIElements Schema" this will create a new folder named "UIElementsSchema" next to your Assets folder. You can then add the generated dtds to you favorite editor.

For css, I personally use standard css syntax highlighing with Notepadd++, but I agree it's lacking for cases where uss diverges from the css standard. I don't think providing a extensions or configuration files for most external editors is in our roadmap, but I agree having one as a starting point would help.

Keep that feedback coming!

 

@bdovaz Thanks for your feedback!

Totally agreed. The current version of the bindings system is really simple and was the bare minimum that was needed for simple editor usage. We are actively working on improving it for runtime and more complex use cases.

Localization is a common use-case and we aim to simplify these workflows in the future.
A few ideas here:
For the time being, most of this will require you to create subclasses of existing controls and provide UXMLFactory/Traits to handle edition in the UI Builder. For instance, here I created a generic wrapper around elements that let's you add your own attributes.

Code (CSharp):

1.  
2. public class UXMLWrapperElement<TVisualElementType> : VisualElement where TVisualElementType : VisualElement, new()
3. {
4.     //A wrapper class for the original class traits
5.     public new class UxmlTraits : UnityEngine.UIElements.UxmlTraits
6.     {
7.         UnityEngine.UIElements.UxmlTraits m_WrappedTraits;
8.  
9.         UnityEngine.UIElements.UxmlTraits CreateBaseClassTraits(Type t)
10.         {
11.             foreach (var innerType in t.GetNestedTypes())
12.             {
13.                 if (typeof(UnityEngine.UIElements.UxmlTraits).IsAssignableFrom(innerType))
14.                 {
15.                     return Activator.CreateInstance(innerType) as UnityEngine.UIElements.UxmlTraits;
16.                 }
17.             }
18.  
19.             return t == typeof(VisualElement) ? null : CreateBaseClassTraits(t.BaseType);
20.         }
21.  
22.         public UxmlTraits()
23.         {
24.             m_WrappedTraits = CreateBaseClassTraits(typeof(TVisualElementType));
25.         }
26.  
27.         public override IEnumerable<UxmlChildElementDescription> uxmlChildElementsDescription
28.         {
29.             get
30.             {
31.                 return m_WrappedTraits.uxmlChildElementsDescription;
32.             }
33.         }
34.  
35.         public override IEnumerable<UxmlAttributeDescription> uxmlAttributesDescription
36.         {
37.             get
38.             {
39.                 foreach (var attr in m_WrappedTraits.uxmlAttributesDescription)
40.                 {
41.                     yield return attr;
42.                 }
43.  
44.                 foreach (var attr in base.uxmlAttributesDescription)
45.                 {
46.                     yield return attr;
47.                 }
48.             }
49.         }
50.  
51.         public override void Init(VisualElement ve, IUxmlAttributes bag, CreationContext cc)
52.         {
53.             var wrapped = (UXMLWrapperElement<TVisualElementType>) (ve);
54.             base.Init(ve, bag, cc);
55.             m_WrappedTraits.Init(wrapped.target, bag, cc);
56.         }
57.     }
58.  
59.     //this way doing .Add() will add to the target instead
60.     public override VisualElement contentContainer => target;
61.  
62.     public TVisualElementType target { get; private set; }
63.  
64.     protected UXMLWrapperElement()
65.     {
66.         target = new TVisualElementType();
67.  
68.         //we want to physically add to this element
69.         hierarchy.Add(target);
70.     }
71. }
72.  
73. public class LocalizedElement<TVisualElementType> : UXMLWrapperElement<TVisualElementType> where TVisualElementType : VisualElement, new()
74. {
75.     public new class UxmlTraits : UXMLWrapperElement<TVisualElementType>.UxmlTraits
76.     {
77.         readonly UxmlStringAttributeDescription m_LocalizedKey = new UxmlStringAttributeDescription {name = "localization-key"};
78.  
79.         public override void Init(VisualElement ve, IUxmlAttributes bag, CreationContext cc)
80.         {
81.             var localized = (LocalizedElement<TVisualElementType>) (ve);
82.             localized.localizationKey = m_LocalizedKey.GetValueFromBag(bag, cc);
83.             base.Init(ve, bag, cc);
84.         }
85.     }
86.  
87.     public string localizationKey { get; set; }
88. }
89.  
90. public class LocalizedLabel : LocalizedElement<Label>
91. {
92.     public new class UxmlFactory : UxmlFactory<LocalizedLabel, UxmlTraits>{}
93. }
94.  
95. public class LocalizedButton : LocalizedElement<Button>
96. {
97.     public new class UxmlFactory : UxmlFactory<LocalizedButton, UxmlTraits>{}
98. }
99.  
100. public class LocalizedToggle : LocalizedElement<Toggle>
101. {
102.     public new class UxmlFactory : UxmlFactory<LocalizedToggle, UxmlTraits>{}
103. }
104.  

A subclass of TextElement (or label) could add prefix/postfix members that would end up modifying the base class text value. Or you could do it with a composite VisualElement with 3 sub labels for prefix/text/suffix. This way alignment layout could be more easily controlled.

We're actively working on improving the bindings and uxml support for runtime and this is the type of use cases we want to address.

These are called Manipulators in UIElements. A simple example is the clickable manipulator. These however are not properly fleshed out yet and the api design needs some improvements. Because of this, most built-in Manipulators used by GraphView (resize/zoom/pan, etc) are still internal.
We have some stuff in the pipeline regarding this in the 2020.x cycle.

You can store a custom object in the userData property of your VisualElements. If you need more than one property, a workaround is to store a List or Dictionary of values in there.

One way to achieve this is to inspect the generated hierarchy in the UIElementsDebugger and figure out the original style classes for Button and Toggle (hint: it's "unity-button" and "unity-toggle") and provide a stylesheet that overrides the default styling values.

The hardcore way to do it, would be to completely remove the styling from your button instances and provide your own. In the builder you can remove the classes from the you can remove classes from the Inspector > StyleSheet section. The Button will display like a default VisualElement, you can then add any class to provide your custom styling. If you'd like to code this once you can to create a derived class from Button that setups the class names and expose it to uxml by providing UxmlFactory/UxmlTraits. Then, designers can then reuse this custom-styled button in the ui builder.

 

@bdovaz I edited my original answer

 

Right now, the only way to use attributes is from within an element's implementation. That is, the consumption logic of your custom attributes has to live in a derived (sub-class). That said, in theory, with our current implementation of UXML, it should be possible to read any attribute on any element that was created from UXML. Extra unused attributes still exist somewhere in the UXML asset. But this is not a high priority feature at this time.

This request is also possible with the current architecture of our attributes system, but again, would take some time for us to implement.

All in all, your feature requests make a lot of sense and I see them being very useful, but for now you'll have to make do with sub-classing. However, you shouldn't have to sub-class each control you want to add your custom logic to (like your localization system). You can create a wrapper element (sub-class just

VisualElement

or

BindableElement

), and have it handle the custom attributes by forwarding the strings to the child control element it is currently wrapping. So you'd have uxml something like this:

Code (CSharp):

1. <Wrapper localization-string="test-string">
2.     <Label name="some-label />
3. </Wrapper>