Any tutorial on the subject (UI Toolkit)?

Unity Engine
1

I’ve been searching all around, but no luck so far

1 Like
2

Something like that? If you have not yet, maybe check out the manual or some source code.

2 Likes
3

yes and no, that’s for UI Elements rather than UI Toolkit, so it is before the renaming and therefore before the “for runtime” update in 2020.1b
Unless anything hardly changed

4

101

1 Like
5

Nothing changed with the rename. Internally everything is still called UIElements. The resources above are still valid

1 Like
6

Nice, I will be checking these out, thanks for the pointers

7

I’ve started writing-up my notes on UIToolkit/Elements, as a series of “Getting Started” blog posts, based on what actually works in 2019 LTS / 2020.1 today (a lot of the older tutorials I read contained a few APIs that don’t exist any more, etc, because they were written when it was all still in alpha, or use approaches that have been replaced by better ones with later API features): 2020 – UIToolkit/UIElements Quickstart guide for Unity Editor scripting – Flexbox 4 Unity

First few posts I’m focussing on C# UI (if you’re doing heavy UI work then it’s more efficient and you can make much more impressive UI than with UXML/UCSS), and Editor UI (because the runtime UIToolkit stuff isn’t really stable enough / strong enough yet - but it’s almost identical, so if you get Editor UI working then it’s only a small step to adapt to Runtime UI as/when Unity fixes/improves it).

If you want to do pure UXML/UCSS, and don’t care about making complex UI, then I suggest just dive in and experiment with the Unity UIBuilder - some people love it, some people hate it, but if you’re only making simple UI and/or you want your players to reskin the UI all the time then it’s probably the best way to build it.

8

I have made a tutorial about UI Toolkit for Runtime :]
Creating a runtime interface of a simple game, using UI Toolkit - UIElements.

Check it out here:
forum.unity.com/threads/course-tutorial-ui-toolkit-for-runtime-new-unity-ui-framework.1016665/

9

Dapper Dino has created a pretty good introductory tutorial covering:

  • UI Builder
  • UI Toolkit
  • handling button click events in C# and
  • updating the display dynamically (UIElements)

See the video How To Create Dynamic UI With The NEW UI Toolkit - Unity Tutorial for more information.

10

Here is a tutorial that shows you how to use UI Toolkit extensively:

https://moetsi.gitbook.io/unity-dots-multiplayer-xr-sample-project/ui-builder-and-ui-toolkit/overview

11

Writing the UI in the C# class is better than using the UXML/UCSS? I was under the impression that, that was the lesser way to do things. Because why have all the mixed up documentation? It’s awfully confusing, I want to practice the most ideal way.

I’m just asking for my own understanding of this subject as I would like to learn this new tool really well. I enjoyed reading your tutorial articles and am really keen on checking out your FlexBox4Unity asset!

12

For my uses - yes. For your uses - maybe, maybe not. I am very happy that both exist! That we can choose which one to use based on each situation! The docs are mostly non-existent for doing it in code, forcing people to use USS even in the cases where it’s a bad decision, so … that’s what I’ve focussed on writing up / sharing. If USS were undocumented, I might have done it the other way around :).

If you’re writing editor/inspector GUI: I’d say it’s usually better to do it in code rather than USS - you get to put all the UI code in one place, in one file! (where it should be: inside the CustomEditor class). Most of the benefits to USS don’t exist in this case: you don’t want users reskiinning it, it’s slower to compile/test/debug USS than to do that in C# code (because - for a custom editor -you’re usually updating C# at the same time anyway), etc.

If you’re doing something which isn’t custom inspectors, then … it depends. Maybe USS is better, maybe not.

For me:
I write a lot of UI that is highly reactive / context-sensitive. Adapts to what the player is doing, has done, where they are in the level/story, etc.
I write a lot of UI that is semi auto-generated from templates.
I write a lot of UI that is Responsive (i.e. adapts automatically to any screensize, and changes the layout based on size + shape (even physical size)).

… those kind of things often work better in code than in USS. It’s clearer, it’s less typing (because you use functions, methods, sub-functions, recursion, etc) and easier to maintain (you have a compiler to detect mistakes!).

13

That sounds amazing! And exactly what I want :slight_smile:
I’m re-writing my game and want to use methods that make sense. I want to create both EditorWindow, Editor, and in-game UI with this new system. I made an EditorWindow recently using UXML and USS so I now have an idea of the flow. I’m excited to try it for an in-game UI, your asset looks to be stupendous for the task! One question though… Will it work on 2019.4? I’m confused by UI Toolkit not being available for 2019.4 but UI Elements is…

Thanks for your detailed reply!

14

To be clear: my asset is unrelated to UIToolkit. My asset is only for people making games (it only does in-game UI, using UnityUI). I use both UIToolkit (for editors) and UIToolkit (for games - but rarely, it’s not really ready for that yet), and my asset (for games - nearly every project, because you can use all of UnityUI, assets on store (nearly all of them are UnityUI), 3D rendering, Particles, etc - some/most of which UIToolkit cannot do yet).

TL;DR: if you’re making Editors / CustomInspectors: use UIToolkit (use USS or C# based on your preference - but I would recommend C# for most custom inspectors and Editors). If you’re making games … you have to choose between “UIToolkit” and “UnityUI + (something like my asset)”.

15

That clears things up a lot, thank you so much! I went ahead and purchased your asset, I can’t wait to check it out :slight_smile: (probably in a week or two)