Feedback Runtime first thoughts and a question

This is a long one y'all, sorry. I'm just excited.

I come to this from a career as a senior webdev, not a game dev or even a regular C# user. So... grains of salt but also I think it gives me some perspective. Also I'm a fan of zenject and DI in general. Also of UI Elements, I am now a fan of UI Elements.

Positives:

• Incredibly fast to use and iterate on. Like... woah.
• Because a lot of my interaction stuff was already designed to accept actions/events rather than be directly wired to interface elements, it was incredibly easy to transition my form code to use UIElements, and ended up being much cleaner. More on that below however.
• Live styling changes are badass and I love it, especially given the fact that I didn't really want to use the UI Builder. I love that you've given me the chance to just .. write xml. I've been doing that for ~15 years and I know how to do it quickly and effectively.
• The ability to create new elements is great, especially given the sorta limited set of built in's. The documentation could be a little clearer (notes below)
• I'm excited about this. I'm going to just work on my game with UI Elements. I don't expect to launch until sometime in mid/late 2021, even if I get more time to work on my project. I know that this stuff is in preview and is highly likely to shift and change, but I. don't. care. It's just that much better.

First thoughts about potential additions/improvements:

• I wish there were a form element or monobehaviour that works with child inputs in a more standardized way so you don't have to wire up buttons manually for generic types of actions. I actually had something like this on hand that was fairly easy to convert, and I'm willing to share as a basis.
• I wish default buttons had a type indicator (Submit, Apply, Cancel, etc) that were usable for the form mentioned above. It was fairly..ish? easy to add that, but it'd be a nice thing out of the box. Allows for a more decoupled approach to form interactions. Even the concept of form/menu doesn't get added, this could make a lot of things easier in the long run for those of us obsessed with loose coupling.
• Related.. I miss having the ability to do data-* attributes. The userData property on VisualElement might be that? I couldn't figure out how to make it work if so.
• I haven't had a chance to look at the Default.uss, but it might be cool if there were a scaffold .uss file that has all of the basic selectors (and possibly some layout defaults?) without color or other more detailed design info. The current default seems to be aimed at matching unity's styling, and while that's great for doing Editor panels, it could make working on a realtime interface style into a game of whackamole.
• I'd love to see the ability to work with UI Elements and Zenject, but I know that's not exactly y'alls domain. That said, it's a bit rough, as the current realtime panel requires a base UXML file and stylesheets set up in advance. There doesn't seem to be a really good way to use an (initially) unconfigured panel and then inject/manage it. That said, it was easy enough (and actually potentially useful) to just put a "form-root" element into a container UXML and then clone the actual content into that.

Documentation thoughts:

• Documentation shifts context from high level overview to implementation details a bit unexpectedly. The technical examples are good, but a bit sparse (Not surprising as this is still a very new technology). It might also benefit from a slight reorganization with overviews separated from the implementation examples, allowing both to be clearer for new users.
• It'd be great to have more class information and interaction examples in the API or in the supported elements list. The Mozilla Developer's Network (MDN) documentation for HTML and JS is a wonderful example of how this could work, though I know that generating this would be a long slog.
• Specifically, the documentation about templates and data binding is a bit lacking given how important these concepts seem to be. The templates are easy enough to do, but it is unclear how to then bind different data into each template, eg.. I can make a template of a player to put into a player list, but I can't tell how to make that list of players represent the different players without having to go in and manually rebind/inject data. This is problematic as it can have the tendency to mix the data, business logic, and view layers. I need to go back to the data binding section, but it was extremely light on the sorta high level overview to tie it all together.
• The documentation for creating new elements could stand to be extracted fully into it's own section, with a full example including UxmlNamespacePrefix() section. It might also just be easier to put it into the demo project, I donno. Regardless, it took me a hot second to sorta put the pieces together.

Implementation question!

So, I've created a couple custom elements in their own namespace, but I'm having difficulty with the

UxmlNamespacePrefix()

implementation. It seems to rely on the [!CODE]UnityEditor.UIElements[/!CODE] namespace, which ... obviously isn't great for a build. Is there a way to register the namespace prefix without that?


Cleaned up example:

Code (CSharp):

1. using System;
2. using System.Collections.Generic;
3. using UnityEngine;
4. using Unity.UIElements.Runtime;
5. using UnityEditor.UIElements;  // PROBLEMATIC BUT NEEDED FOR THE UxmlNamespacePrefix
6. using UnityEngine.UIElements;
7.  
8.  
9. [assembly: UxmlNamespacePrefix("SMG.Common.UserInterface", "smg")]
10.  
11. namespace SMG.Common.UserInterface
12. {
13.   // .. stuff in here
14. }

 

Probably should have separated out the problem/question into a separate post. <_<

 

I would love a top level window, though I suspect it would be better to disconnect the form handling from the window so you could handle multiple forms in the same window, or submit a form without closing the window. I created a gist with an example form from my game if you're interested in seeing a first pass. https://gist.github.com/polerin/d93feca1f69534e1e64374324bbaf3cc

Awesome on the rest, up to the zenject. I was a little unclear on what I was meaning there, mostly I was hoping for the ability to inject a .uxml and any number of .uss files into the panel after creation, instead of having to wire it up in the inspector. It'd make for a more flexible system, though I can do some of that with prefab variants.

Any guidance on custom elements during runtime? I'd really like to be able to use my FormButton, but I can't figure out how to get the UxmlNamespacePrefix() to work without including UnityEditor.UIElements.

Thanks for the work, and I'm glad my feedback was useful.

 

Any word on the issue with runtime support of UIElements that reside within UnityEditor.UIElements namespace?

 

Code (CSharp):

1.     // UnityEngine Controls
2.     // Default Controls
3.     private UnityEngine.UIElements.VisualElement VisualElementControl;
4.     private UnityEngine.UIElements.Button ButtonControl;
5.     private UnityEngine.UIElements.Scroller ScrollerControl;
6.     private UnityEngine.UIElements.Toggle ToggleControl;
7.     private UnityEngine.UIElements.Label LabelControl;
8.     private UnityEngine.UIElements.TextField TextFieldControl;
9.     private UnityEngine.UIElements.Foldout FoldoutControl;
10.     // Numeric Controls
11.     private UnityEngine.UIElements.SliderInt SliderIntControl;
12.     private UnityEngine.UIElements.MinMaxSlider MinMaxSliderControl;
13.     // Container Controls
14.     private UnityEngine.UIElements.ScrollView ScrollViewControl;
15.     private UnityEngine.UIElements.ListView ListViewControl;
16.     private UnityEngine.UIElements.IMGUIContainer IMGUIContainerControl;
17.  
18.     // UnityEditor Controls
19.     // Default Controls
20.     private UnityEditor.UIElements.ObjectField ObjectFieldControl;
21.     // Numeric Controls
22.     private UnityEditor.UIElements.FloatField FloatFieldControl;
23.     private UnityEditor.UIElements.IntegerField IntegerFieldControl;
24.     private UnityEditor.UIElements.LongField LongFieldControl;
25.     private UnityEditor.UIElements.ProgressBar ProgressBarControl;
26.     private UnityEditor.UIElements.Vector2Field Vector2FieldControl;
27.     private UnityEditor.UIElements.Vector3Field Vector3FieldControl;
28.     private UnityEditor.UIElements.Vector4Field Vector4FieldControl;
29.     private UnityEditor.UIElements.RectField RectFieldControl;
30.     private UnityEditor.UIElements.BoundsField BoundsFieldControl;
31.     // Value Controls
32.     private UnityEditor.UIElements.ColorField ColorFieldControl;
33.     private UnityEditor.UIElements.CurveField CurveFieldControl;
34.     private UnityEditor.UIElements.GradientField GradientFieldControl;
35.     // Choice Field Controls
36.     private UnityEditor.UIElements.EnumField EnumFieldControl;
37.     private UnityEditor.UIElements.TagField TagFieldControl;
38.     private UnityEditor.UIElements.MaskField MaskFieldControl;
39.     private UnityEditor.UIElements.LayerField LayerFieldControl;
40.     private UnityEditor.UIElements.LayerMaskField LayerMaskFieldControl;
41.     // Toolbar Controls
42.     private UnityEditor.UIElements.Toolbar ToolbarControl;
43.     private UnityEditor.UIElements.ToolbarMenu ToolbarMenuControl;
44.     private UnityEditor.UIElements.ToolbarButton ToolbarButtonControl;
45.     private UnityEditor.UIElements.ToolbarSpacer ToolbarSpacerControl;
46.     private UnityEditor.UIElements.ToolbarToggle ToolbarToggleControl;
47.     private UnityEditor.UIElements.ToolbarBreadcrumbs ToolbarBreadCrumbsControl;
48.     private UnityEditor.UIElements.ToolbarSearchField ToolbarSearchFieldControl;
49.     private UnityEditor.UIElements.ToolbarPopupSearchField ToolbarPopupSearchFieldControl;
50.     //Inspector Controls
51.     private UnityEditor.UIElements.PropertyField PropertyFieldControl;

Many of the built in controls are not accessable during runtime as referenced above.

 

Like the OP I kinda expected there would be some bootstrap-esque "best practices" template uss stylesheet and also some hooks so you could potentially do your own bindings like knockout, vue, angular etc do where you could have people add their own custom bindings to elements with more of a focus on MVVM.

I see the binding path stuff but it seems quite convoluted, like you need to wrap the object in some serializable thing and seems to be focused on unity objects (MB/SO) rather than just any C# object (like I have a tree of complex POCO objects inside most of my unity objects). In Web UI frameworks you may have a few bindings such as on a drop down you may want to bind the options, the selected value, the field to get text/value from in the options list passed in.

If you were to have MVVM style features you could also potentially do more logic within the view such as having `if` statements to decide if you should render certain elements depending on something else happening, at the moment im having to do loads of wireup behind the scenes which in the web world would just be bindings put on various elements to tell them what to do. As well as being able to wire up callbacks on the uxml objects themselves, but then maybe this makes it a bit too heavy weight to be put in as the base offering from unity.

If this extensibility bit was all in place you could have people adding custom bindings and have frameworks built on top of uxml/ui toolkit which would let developers do all of this for you. Knockout is a great example of simple MVVM-Lite implementations, I always found the stuff in WPF a bit verbose in comparison (Vue is a great library too as its taken what knockout brought to the table and ran with it).