Hi! I write my editor tools using OnGUI and OnInspectorGUI methods. Is there a plan to maintain the possibility of creating a custom editor UI using those, or do you think about deprecating the API in the upcoming years?
Hi @ProceduralPixels and thank you for the question.
Our intention is to consolidate our UI systems into a single one so that eventually, when it is ready, UI Toolkit will replace both IMGUI and UGUI. Until that day, we remain committed to maintaining these two systems. We will communicate obsolescence ahead of time to give everyone enough time to adjust.
Is there a particular reason you prefer to use IMGUI instead of UI Toolkit?
Thanks for answering!
I have a few reasons for using IMGUI over the UI Toolkit, and I consider depreciation of IMGUI as a step back. Here is why:
- I’m a developer and developing many custom debugging tools and editor tools using IMGUI during my work. I also developed my custom library to develop GUI layouts more quickly. This allows me to create UI elements quickly without exiting my IDE, which boosts the workflow.
- I’m an asset publisher, and my asset uses custom inspectors and editor windows made with IMGUI. Depreciation of IMGUI will require me to port all of my work to the UI Toolkit, which will be time-consuming. And I need to consider this change from business perspective.
- IMGUI solution is commonly used outside of Unity in the areas that I would also like to work (prototyping, other engines, graphics debugging). UI Toolkit is Unity’s proprietary tech (somewhat reassembles web development, but I don’t want to work in web-dev). Using IMGUI gives me a better perspective as a developer in case I want to move to a different industry where IMGUI is also used.
I’m okay with UI Toolkit being the main way of developing the UI in game, but I’m not a fan of removing IMGUI from the engine, due to the rapid workflow and prototyping possibilities. And I don’t understand why you want to do this (or if you want to do this). What is the reason for that?
Thanks for the feedback.
We understand where you’re coming from. Having to convert existing tools for no apparent reasons is not a good return on investment for your business.
Unity invested in UI Toolkit to allow tool developers, internally and externally, to build more complex workflows. You’re right in saying it’s very efficient to write small UI snippets with IMGUI, but it then scales very poorly, both in performance and maintainability. Before deprecating IMGUI, we’ll need to add a faster way to write UI Toolkit code for very small use cases.
UI Toolkit is also increasingly more capable as a framework, providing better styling and layout, more widgets, and animation. And more will come as we continuously invest in it, with better support for accessibility, visual effects, and vector graphics.
Our goal is to make sure the UI Toolkit provides enough value to developers, so we can eventually focus on a single solution. Keeping three separate UI systems in a complex environment like Unity is expensive and can hurt the user experience.
Hope this brings more clarity on our decision.
Cheers
I understand that we need to move forward sometimes. As long as the UI toolkit provides API designed for quick prototyping, and we are all informed well in advance, I’m all set! Thanks for the response.
Is there any chance that some of these UI-Toolkit improvements will come during the Unity 6 generation cycle?
I would e.g. very much like to use the vector drawing capabilities of UI-Toolkit to make resizable shapes but I need to fill those shapes with a texture, which is not currently possible I believe. From the roadmap at Unite I understood that major improvements will not come before Unity next generation which would still be a few years in the future.
Hi @Milvulus, we’re still evaluating what improvements we’ll be able to release during the Unity 6 generation cycle.
I’m taking note of your request for filling vector shapes with a texture.
Thank you, much appreciated!
I do not like the new object system. I like writing my gui code. I write wargames and the new system is a pain in the ass for all the data I have to write. I can look at code with no issues. But I can’t remember 25 clicks to set up a text in my game through your system.
There are enough game devs that LIKE coding their GUI.
You can still do a very code-first approach with UI Toolkit. Can’t go 100% code based, but easily a good 80-90% depending on what you’re doing. This is my general approach with UI Toolkit.
Though if you’re a fan of an IMGUI based UI approach, I would keep an eye on PanGui: https://www.pangui.io/
The UIToolkit layout uses Facebook’s Yoga. Facebook also made Litho which is kind of like a builder style of making UI though code. I’m currently trying a similar method in UIToolkit. I also like using the Material 3 theme. For databinding I tend to use R3 for the view model so I don’t need to do control queries. Because I’m building it in code I’m also testing out binding the theme to reactive properties rather than USS. So if I wanted to I could change it to lua and build the UI dynamically e.g. news (unlike uxml which can’t be parsed yet).
So for a basic dialog it might look like the following (can change localization / theme at runtime).
So my view model might look something like this:
public record BasicDialogViewModel<RESULT>
(
ReadOnlyReactiveProperty<Sprite?> OptionalIcon,
ReadOnlyReactiveProperty<string> Headline,
ReadOnlyReactiveProperty<string> SupportingText,
ReadOnlyReactiveProperty<IViewModel[]> Buttons,
ReactiveCommand<RESULT> ResultCommand,
CompositeDisposable Disposables
) : ViewModelBase(Disposables);
I then have a factory to build the UI in three stages. The first creates the state e.g. if the dialog has an icon then align center, else align left. Then it goes though a layout stage e.g.
core.CreateColumn(vm.Disposables).Name("basic-dialog").GetSelf(out var basicDialog)
.ChildIf(() => state.hasIcon, () => core.CreateImage(vm.Disposables).Name("icon").GetSelf(out icon).Sprite(vm.OptionalIcon.CurrentValue))
.Child(core.CreateLabel(vm.Disposables).Name("headline").GetSelf(out var headline).Text(vm.Headline))
.ChildIf(() => state.hasDescription, () => core.CreateLabel(vm.Disposables).Name("supporting-text").GetSelf(out supportingText).Text(vm.SupportingText))
.Child(core.CreateFrameView(vm.Disposables).DataSource(vm.Buttons).Name("buttons").GetSelf(out var buttons));
Reactive properties make it easy to sync the data to the UI e.g.
var title = new ReactiveProperty<string>("Test title");
// or var title = localizationService.Localize("Demo", "Demo.UI.Dialog.ConfirmResetSettings.Headline");
core.CreateLabel(vm.Disposables).Text(title); // Displays "Test title"
title.Value = "New title"; // updates UIToolkit label to "New title". Doesn't require access to any UIToolkit components.
Finally it applys the style with the outputed controls from the layout e.g.
layout.icon!.TintColor(theme.Secondary).BeginStyle().TransitionDuration(md.Sys.Extra.TransitionDuration).
Width(24).Height(24).MarginBottom(16).AlignSelf(state.align).EndStyle();
One thing I like about this is that I can add things not supported by the builder UI like the Image component or a gap settings (to add a space between the buttons). You also don’t need to add all the components and hide them e.g. if I don’t need an icon then don’t add it. I do still find IMGUI a lot quicker for making simple editor UI.
Thanks guys for suggestion. I made my own UI system within IMGUI to do extra things. I just don’t want Unity to get rid of it. It also uses less code.
Like my tool tip utility is one object with a script attached, one guistyle, and maybe 30 lines of code.
Simple.
The new way is way more complex.
Yeah, I hope they keep IMGUI as well. I find UIToolkit interesting for runtime experiments but it’s completely overkill for any editor tools. I’m really surprised that they might be looking at replacing UGUI as well. UIToolkit is ok for the flat/html style UI that I’m currently working on but I’d hate to try and use it for something like a Persona 5 UI. On the plus side Unity tends to take its time with updates, so I’m expecting it will probably take about a decade before it’s replaced.

