Search Unity

Feedback UI Builder needs a public API

Discussion in 'UI Toolkit' started by Windwalk_Rosco, Oct 8, 2021.

  1. Windwalk_Rosco

    Windwalk_Rosco

    Joined:
    Aug 10, 2020
    Posts:
    20
    I've been using UITK and UI Builder in our runtime for a few weeks now and felt it might be good to put some thoughts together. UI Builder is a super useful tool. It allows really quick development and iteration with immediate feedback.

    However, it desperately needs public API access. While the default built in controls are great, there is always going to be a need for custom c# controls. Right now, it is a juggling act to make those controls be usable within the builder.

    In our case, we needed a way to navigate between multiple menu screens. I started trying to break each screen into separate UXML templates, but it became quickly apparent that was useless. Templates get wrapped in a Visual Element when instanced meaning you can't automatically apply any consistent styling to the root. In the case of a menu screen, I had to still go in and add styling to each instanced screen so that they positioned correctly. Additionally, this setup required the parent doc to do manual Queries and hookups for all the screens and navigation controls. This made creating a new screen fairly intensive, which is not ideal.

    I decided to move away from templates and into custom controls. UXML wise this works great. I can attach c# logic to each menu screen and navigation button to automatically hook navigation interactions up together by using a string screen-id attribute. However, to make the Builder usable without any sort of api was a massive headache. You can't edit a screen if all of them are visible at once so you need a way to control which is visible. I ended up adding more attributes to control which screen was being displayed in the builder view and only use that logic if the application wasn't playing. An issue here is that data now needs to be saved into the UXML and then it gets committed into git, while it doesn't have any runtime use.

    For this case where I could use an int index to control the active screen it works okay, but I can easily see more complicated controls making the UI Builder unusable without being able to customize how you author them. Right now you can't control logic for which children/parents are allowed, how attributes are saved, where/how controls are displayed in the library (why are they in a separate tab from built-in and forced to be in a tree?).

    As a side note, I also can't see a strong use case here for ever using templates? The idea is to build atomic pieces of UI which sounds great, but that atomic piece gets wrapped in a VE container which you can't style atomically. You could select them with the name since that defaults to the template's name, but then what is the point of an atomic unit if they are all forced to have the same name? The isolated editing is nice but why couldn't that just be a feature on any VE in the hierarchy?
     
    Timboc likes this.
  2. sebastiend-unity

    sebastiend-unity

    Unity Technologies

    Joined:
    Nov 9, 2015
    Posts:
    184
    Hi!

    First of all, thank you for that precious feedback. You make absolutely valid points and just know that our teams are looking into this and are aware of your feedback. We are of course contemplating the idea of a public API but want to be cautious as much as possible. Public means forever(TM) as you know :) Your feedback makes for a very nice use case.

    On the last point, I think once you reach an appreciable nb of elements, it can become a good idea to separate concerns and use templates. Just for organization purposes it can be useful.

    I think what we are working on right now can help you in the near future. Keep the feedback coming.
     
    Timboc and Windwalk_Rosco like this.