Official Draggable overlays, custom toolbars, new Tool systems

Looks great, is there any plans to support these in builds as well? Using the same debug tools/overlays at runtime would be a huge benefit.
Considering UIToolkit is going to support runtime, and this seems to be making use of UIToolkit, maybe we could access the container so that we can display it at runtime ourselves? Would be neat if possible.

 

this looks VERY promising, I'm excited!

 

Please turn this thread into a sticky, so it won't get lost. Everything in those videos look great, all thumbs up. Out of curiosity, how long did it take how many people to get this far?

 

Looking forward to these changes!

 

Things are starting to get closer to the UI Mockups for a few years back. My body is ready.

 

That looks super promising! I think that'll be a big boon for lots of editor tooling & third party packages. One question though, if you at this image: The pink space is unused. The pink underline is for buttons I never use. Layouts could be a dropdown along the other menu items. The play buttons could go... somewhere. To me that's awfully close to freeing up that entire bar of space! Now just combine that with incorporating the menu items with the title bar, and we're really in business.

 

Both layouts and layers would be 10x more useful if they were small dockable windows, layers could even be an overlay of the scene view (as there is no utility outside there).

Play, pause and step button could be on both Scene View and Game View top bars

Collab and services have their own windows already, no need there.

Account could be on Help menu together with Manage License.

Yeah, let's get rid of that top bar!!

 

Looks nice AND sensible (heck, I wish I could say the same about other parts of unity...).

Any plans for the "status bar"? I'm not really fond of it tbh, vertical space is a premium.

 

Nice! Personally probably would be happiest to just have the space back, but quick shortcuts in that bar sounds like a great use. If shortcuts become a thing it'd be great to bind MenuItems there, as I think lacking those currently lots of assets put shortcut like things there.

 

This is incredible!
I feel like Unity is finally becoming modern!
@gabrielw_unity, where were you all my life? We needed this years ago!

Really though, there are reasons I stick with Unity through all the countless errors, half-baked features, and questionable management — and this is one of those reasons.

Now not to get off-topic or anything — but since you seem like you'd possibly be the guy to know, are there any plans to rethink the Inspector? I really need tabs to sort my Components by specifiable and customizable groups or I'm going to die.

Also, @awesomedata, I think you're going to like this thread.

 

Thanks for sharing those videos.
I think mostly this feels fine (and getting tools to be consistent is important), but I have some questions / notes:

Conversion path for existing tools. I tried to get a few people onboarded to the EditorTools API, and many mentioned that they do not want to (right now) support something that they cannot easily integrate, as turned out for the EditorTools API.
I tried porting some of our own tools over to this, and the issue here is that often "tools" are implemented on top of Components / MonoBehaviours, and are thus very context-specific to the selected components. At least from my tests so far it didn't feel "easy" to make these use the new API, mostly because an "EditorTool" has no understanding of selection per se and it seems quite a bit of boilerplate needs to be implemented just to "forward" a tool command to a specific, currently selected component or set of components.
So the question here would be: are there samples for component-specific tools and how to implement them properly? Or, to put it differently, can I tap into the EditorTools API from a custom inspector directly, instead of having to make an EditorTool that then somehow figures out what is selected and provides the right details?

Shortcuts. It seems this is a missing key piece from the videos: shortcuts are important for specific tools and scenarios, and current solutions like the Shortcut Manager only deal with global shortcuts, not context-specific ones, those are "on the roadmap" for a long time now and nobody seems to be working on it. It seems from the 2nd video that you're in fact planning for Shortcut Manager integration, but this would be a big issue I see with that.
I do not want to remap a million keyboard keys and make sure that they don't overlap as is the current situation with tools; I just want shortcuts to be forwarded to whatever tool is active and handle them there, and then they can "bubble through" to the rest of the editor if they aren't handled (just one way to deal with this, there are surely more).

Multiple Scene Windows. One big advantage of the tools section being at the top was that screenspace was saved, all scene views stayed clean. With the tools section moving into the scene view, what happens when I have multiple scene views open? Do the tools jump around with me? What happens to that "floating thing layout" I manually did by positioning them with scene views of different sizes? Or, in the case that each scene view comes with its own configuration, can I copy / paste configs to other scene views?

Contextual Tools. As mentioned in the "Conversion" question already I believe most tools are very context-specific. How will the screen space be leveraged for those? If I have 10 different MonoBehaviours that come with different sets of tools that are just relevant to them, it seems like I would be wasting a ton of screenspace by always having to have all their tool containers open, or I would need to constantly reconfigure my scene view to show just the tools that are relevant for that selected object. As mentioned before, it would be great to have the option to use the EditorTools API directly from a custom inspector and configure what is shown there - as done today through hooking into OnSceneGUI, but my understanding is that you want to clean this all up and have everything go through the new API.

Additional Customization and Tools that affect the project, not scene. There's more to the UI by now than just the scene view and tools section. I understand that these might be treated by different teams inside Unity, but as a user, I'd like to also configure/dock to e.g. the right side of the toolbar (the area where Collab etc are). This is especially true for those tools that are project related and not scene related.

Looking forward to more details on those!

 

Wait, this is f*ing great. Wth. It is so much better than what I expected. You can even get rid of the annoying default toolbar I've wanted to destroy for years.

I love this. Can't wait to see it alongside the better window management when that comes. Will be testing it out and reading some comments here, just wanted to say all of that asap, it took me by surprise and I really feel like saying something is good when I think it is.

 

Could we please dock tool bars in the top alongside the play buttons, unity cloud buttons, Collab buttons, and regular control buttons up at the top? It would be great to be able to dock custom stuff there.

 

I'd very much like to have Workspaces and more functional toolbar. Changing Editor layouts with a click or kind of browser tabs would be perfect for any workflow I can imagine.

 

I'm using `EditorTool` at the moment, and i'm sorely missing callbacks to know when its been activated and de-activated. Is that something that will be added?

 

@TJHeuvel-net I believe you can use the EditorTools.activeToolChanged callback to do that. Example

 

Looking at my toolbar, you will see how much I am waiting for this !

Also I use and abuse a lot of components tools (even on the native Unity components), combined with scene view Tiny Window, see the foldable "Extensions" on the Transform component:
http://www.belfiore.ovh/devlogs/lock-children/lock-children.php

I have multiple question:

• We desesperatly need some API for some of the most common callback with global tools:

- Callback when unity loaded (et all assembly / asset are loaded)
- Callback when a scene open / close (editor + play)
- CallBack when the project just recompile (it often break non serialized & non static tools)
- When Entering / leaving play mode
I know every of this callBack are currently there in unity (not for the "unity just loaded though...), but when I create a global tool, every time I have to create this different callBack (and with that, make the tool static... because these callback work for static tools)

• Also, I would like a way to easly SAVE settings for my interlal tool settings. The only clean & stable way is to use EditorPrefs. (dynamic scriptable Object only for tools is hard to manage, we have to save an asset. This asset can move, be lost...)

I have so much to ask, but I will control myself x) Keep working!!!

 

Thanks, looks useful! Also looks like a lot of code, a `SendMessage("OnToolBecameActive")` would still be preferrable.

 

@LeonhardP pretty please? (sticky for the thread)

 

ScriptableSingleton looks like a good solution for this. You get to say where the file goes, if it's shared between team members or per-person, and then you just have a place to stuff arbitrary data.

 

Isn't the new way to use the UserSettings<> class and UserSettings directory?

 

@Peter77 UserSettings is for user-specific settings (e.g. log in data, local disk paths, your personal preferences, ...). ScriptableSingleton together with the FilePath attribute provide a way to specify where that particular data goes (ProjectSettings, Preferences, and I believe also UserSettings) – but let's keep this thread about Toolbars and Tools

 

Will this type of functionality be coming to windows like Shader Graph, VFX Graph, etc? Or is this just for the scene view atm?

I personally don’t like the always-floating panels in Shader Graph, and being able to dock panels would be so nice

 

Thanks for sharing this. One concern I have is will all these improvement further slow down Unity editor more and more during opening the project and working on project as it seems like every new Unity version will further slow down performance? Does it implemented internally based on UI Toolkit? Another I hear is GTF will be used to implement visual scripting. Will GTF be used to rewrite Shader Graph as current performance of Shader Graph is still too slow.

 

@gabrielw_unity the Component Tools overlay might solve part of that, thanks for sharing this. However that feels pretty limited then, as I could only have that single overlay and lose the actual overlay customization options, is that right?

@kaarrrllll thanks for the detailled write up, and especially for the example code. It would be very helpful if that ended up in the docs!
A note, the link to EditorTool.OnActivated leads to an internal-only view of the docs I think.

Regarding shortcuts, that "context" would in the case of scene view tools obviously always be the scene view, so unfortunately this isn't a very helpful feature here. I had some discussions in the Shortcut Manager forum thread about this, and the consensus was "sorry, right now it's impossible to build this kind of selection-specific shortcuts with this", so I certainly hope that will change to make overlays and editor tools more useful.
Virtually any other professional software has a way to "overload" shortcuts depending on selection and/or context, so I really hope this will be added

 

This is all awesome stuff. Can't wait to use it and make some nice tools

 

Yes, that should be amazing!

 

This looks really good! The current state of Unity feels like everything does not belong together or that unity is filled with 3rd party plugins but this looks promising!

 

I have also a 2 special request: (may be not related to EditorTool, but intimately linked...)

1) Component Build:

I would like an event triggered ONCE when a component is just added (from runtime / editor script, OR from editor)

Example: When a new component is added, I want to assign to it some special default variables, like gameObject reference, or structures initialization... Only the first time.

• I don't want to use Awake() & [ExecuteInEditMode], because, Awake is also called on play at runtime
• I don't want neither use the Constructor (because it's called at compilation, when leave/back play mode...)

• What I can do, is create an editor for the special component, then create a Serialized hidden bool "IsBuilt" on the component, and then on the OnEnable() of the Editor script, Do my stuff to initialize my component is this IsBuilt is false (and use Serialized property of course. By the way: Serialized property is REALLY HARD to master for beginner, et realy really anoting, we need some wrapper and EASY TO USE API for that...).

2) New init method for editor scripts:

Sometimes, we want stuff to be initialized inside an editor script. Then we commonly use OnEnable().
But sometimes, we can't. Sometimes with special GUI stuff, of texture initialisation, I have to init my stuff at the first OnGUI(), or at the first OnInspectorGUI(), or at the first OnSceneViewGUI().
It would be nice if we had virtuals method for these...

My solution is to use a Decorator for every problem I mention, but it should be native I think.

 

While I think what you mentioned may be a useful feature to people, and I am in no way dismissing it — have you tried taking a look at Reset() and determining whether or not it would be sufficient for your needs?

Reset is Editor-only, but in most cases you really shouldn't be adding Components to GameObjects at runtime due to the insane performance hit that occurs, so perhaps Reset is enough for your usecase?

 

Looks great! I would love to see is that these tools work on runtime in the editor for prototyping.
I really miss probuilder on Runtime.
Will that be possible anytime soon?

 

Simply amazing, the overlay mode will be very useful ... I will be waiting for the next Alpha releases to test this wonder

I don't know if you can fix this, but in the dark theme of unity, the bars at the top of the screen are white, you can make it black. please

 

Just came across this on twitter. This looks amazing. Thank you for this update and roadmap. Looking forward to it.

 

Alright! Thank you for the Feedback, i look forward to it

 

Unfortunatly, this Reset() is called from the Monobehaviour script (and as tool programmer, we want a way to clearly separate gameplay code from editor code). So I would like this Reset() function to be called on the Editor Script.
(is it possible ?)

I think we derived a bit from the subject, sorry for that but it's some nice talk thought.

 

This is looking really pretty. I like what's going on here! As someone who just pushed his first tool to the asset store, a lot of these features are solve many of the little gotcha's that I had to hack my way around to get a tool that behaves consistently in the Unity ecosystem. Neat! I look forwards to being able to update my tool in a year.

 

Any updates on availability?

 

This is amazing work, guys! -- I have a few requests though:


@gabrielw_unity

Shortcut Manager -- Is it going to be able to apply "Per-Workspace" and/or "Per-Toolbox" shortcuts alongside this new system so I can toggle all visual overlay components from a different workspace (and Toolbox) on/off?
I hate modifier keys too -- so I'd prefer to activate most tools via single-button presses (i.e. "G" key for toggling a grid).



I need a "Per-Toolbox" option where an entire "Workspace" can actually have up to 8 different "Toolboxes" active (one at a time though) with a small selection of Toolboxes (i.e. 1-8 Toolboxes activated/toggled by the 1-8 numeric hotkeys) -- each "Toolbox" has its own (assignable) shortcut keys.
Setting a Toolbox as "Toggleable" would keep its shortcuts (though not its overlays) active even when another Toolbox is active, but by default only one can be active at a time. However, a "Main" Toolbox for the Workspace would be necessary (whether it's active or not), so only one Toolbox (out of all 8 Toolboxes) can be set as "Main" Toolbox (which essentially just handles default shortcuts when no other Toolbox/Tools are active in the Workspace).


The idea is that my global shortcut keys can be single-key (and changeable on-the-fly depending on the "Toolset" out of the active Toolbox I choose for the active Workspace).
Toolset mechanism would essentially show/hide overlays / component toolbars / etc and activate their various shortcuts when a Toolset becomes active in the active Toolbox + Workspace. Shortcuts and Toolsets are swapped automatically based on the Toolbox chosen and activated in each Workspace. Not only that -- but it would keep my ever-increasing toolsets more organized with the concept of an actual Toolbox/Toolset hierarchy. This is a concept no other application I've ever seen before has -- but Unity is unlike any other application in the sheer variety of tasks, tools, and operations it can become, right?

Ideally, all my keys in a Workspace / Toolbox should be able to be set to single-key operations for swift/instant activation of tools/windows/etc. (i.e. "G" key to toggle grid when placing tiles with a 2d Tileset Toolbox -- regardless of the placement/rotation/etc tools itself -- but "G" opens up my graph when working on Visual Scripting with the "Programming" Toolbox active -- with all these Toolboxes available on particular numeric keys at the top of my keyboard, all instantly available within my "GameDev" Workspace.) Other workspaces + toolboxes would then have their own shortcuts (and management) for each of the 8 possible Toolboxes (and however many Workspaces one needs).

How does this sound?