Search Unity

Feedback Runtime first thoughts and a question

Discussion in 'UI Toolkit' started by polerin, Jan 16, 2020.

  1. polerin

    polerin

    Joined:
    Apr 11, 2013
    Posts:
    7
    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. }
     
  2. polerin

    polerin

    Joined:
    Apr 11, 2013
    Posts:
    7
    Probably should have separated out the problem/question into a separate post. <_<
     
  3. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    160
    Hi polerin and thanks for this incredible feedback. There’s a lot to unpack and I’ll try to address some of your points.
    Having a higher level type, like a panel or window, is something we're talking about. It would generally make things easier for authoring but also to embed some expected behaviours regarding navigation and screen transitions. I like your idea of also consider form related controls and behaviours.
    We’re currently re-writing the whole documentation, which will include way more examples.
    Yes userData is the only feature we provide for now, which is only accessible via C#. Having something more flexible and declared in UXML is something we consider.
    Agreed! The new major iteration of the framework will come with a runtime theme that is easier to customize.
    I believe it's possible to have an empty PanelRender and then generate everything in code.

    Thanks again for sharing with so much details. Very helpful.

    Cheers,
     
  4. polerin

    polerin

    Joined:
    Apr 11, 2013
    Posts:
    7
    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.
     
  5. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    160
    What I meant is you can access to the root of the PanelRender in C# and dynamically add anything in there without having to specify assets in the Inspector. I believe the visualTree property is the actual root of that panel.
     
unityunity