UI Roadmap

It's pretty safe to assume a preview period for any package at this point, so I would say yes. We would want user input before we freeze the API in a full verified package.

 

It's something we hope to get to but while 2020.2 is a reasonable target, it's a bit early to give an exact version we'll have this in by.

All I can say is that grid layout is not off the table forever. It is something that keeps coming up so we know it's wanted but we really want to ship UIElements with flex-box layout first - so UIElements, as a whole, does not take 5 more years.

 

UIElements is 95% C#, with some low-level rendering and bindings code still written in C++ (Unity core). Unity itself dropped support for Javascript a long time ago so that wasn't even an option.

Regarding use of web assembly and existing toolkits, UIElements is custom built for Unity and uses Unity's rendering systems to display itself. It needs to work with Unity types and interact well with other features of Unity.

 

Hi folks, we posted an update regarding runtime support: https://forum.unity.com/threads/uielements-roadmap-update.784388/

The roadmap in this thread will reflect those changes shortly.

Cheers,

 

Roadmap updated.

 

This has been put on hold momentarily while we integrate TextMesh Pro in UIElements. It will get back on the roadmap but I have no ETA.

 

A preview package is still planned for 2020.1

 

Two things.
1. SerializedObjects and SerializedProperties in the Editor (bindings in the Inspector window) will not go away anytime soon. As such, UIElements will continue to support the main Unity binding system.
2. It's not set in stone yet, but there's no obvious reason right now why the new runtime bindings system that UIElements will use at runtime won't also work in the Editor. This means that the new system should be fairly unified across all UIE usage. That said, our priority will be first to make it work at runtime.
3. Whichever bindings system you end up using, the way bindings are hooked up in UIElements will stay the same between them.

 

UI Toolkit is just the new name for UIElements. All existing docs on bindings in UIElements still apply to UI Toolkit.

 

UI Toolkit (formally named UIElements) does not currently have public APIs to let you define your own binding system. Also, the existing bindings system only supports binding of the

value

attribute on some fields. It does not support binding to arbitrary attributes or styles properties. Finally, the current bindings system only works in the Editor using SerializedObjects and SerializedProperties.

We are working on a better solution as part of our plan to add bindings support to the Runtime (so not rely on SerializedObjects). But there's nothing you can build upon at the moment.

With that all said, you don't need a binding system to implement your own binding system. All the basic APIs are already there. You just need to tap into UI Toolkit's Event system to know when fields have been changed by the user - and use your own binding system to tell you when to update the UI. You can implement this on top of the current APIs using your own C# Attributes (ie.

[Bindable]

).

 

Extending the UI Builder's own inspector is in the plan but will likely come after the release of UI Builder 1.0. We know it's an important feature though.

 

You're right it's very important and that's why we're making sure it's available in the first public release of the runtime package.

 

I'm referring to the Verified package that will release by end of year, which will have support for text tags.

The one releasing for 2020.1 will have basic formatting, like Bold and Italic, applied to an element only.

 

I doubt it will in 2020.

 

Also in the backlog, no timeline to share though.

Text in the UI Toolkit is powered by TextMesh Pro and will support the Font Assets, which allow to generate bitmap fonts in addition to SDF. This should provide the desired effect.

 

If not in the first drop, soon after it.

 

Very unlikely, we're no longer investing in UGUI.

The team's goal is to make sure that the UI Tookit outperforms UGUI in the most common scenarios. The new layout engine and renderer combined with improved controls such as the ListView, should help making sure that no resources are needlessly spent on rendering UI.

 

Let's agree on In all common UI scenarios.

The reason I'm cautious is that some people will always use a technology to build things it was not meant to, and we don't want to be held accountable for those scenarios as well.

 

It's for "or later". Definitely something that will come after the initial 1.0 release of the UI Toolkit package later this year.

 

I'll let @benoitd_unity answer what he meant specifically.

But generally speaking, no one approach/tech/paradigm will solve all problems equally well. We decided to go with a Retained Mode UI system because, among other benefits, we think the problems Retained Mode UIs solve well are more frequent among Unity users than the problems they solve less well.

Specifically, UI that changes _entirely_ every frame is seen less often in games compared to UI that has a lot of static parts. Most UI will not have the layout of buttons and labels constantly change so we can benefit from optimizing and redrawing only what needs to change.

We will do our best to optimize UI Toolkit for the worst case (everything is changing every frame) but that's not our primary use case so for those cases, another solution specifically optimized for those cases might perform better. Hence, we cannot claim that UI Toolkit will _always_ be faster than every other solution/approach. That's just not realistic.

 

This is getting a bit philosophical but this idea that a tool can be used for something other than what it was meant for applies to all tools, including the very
> ...cutting-edge stuff where a lot of people might say "this is not how the technology was meant to be used!"
What you build will also have use cases it was not designed for and may not perform as well as a different tool that was designed for those cases. This cannot be avoided.

At Unity, we try to imagine and gather from users as many possible use cases as we can when we work on a feature. But then there are resource constraints and mutually exclusive requirements to contend with which means we will have to make choices that favor one use case over another.

That said, to be clear, the message here is not:
> Do not use this tool for X, Y, and Z because it was not designed for those use cases.

The message is more like:
> If you use this tool for X, Y, and Z, you might not get optimal results because it was not designed for those use cases. But we will do our best to help you successfully use it for X, Y, and Z, anyway.

So, please do push our tools beyond their specs. We don't want you to stop doing that. We're just trying to manage expectations.