This will be a slow process and it's not our focus right now. Runtime will be the main focus, as well as new Editor UI. But..."eventually". That said, even if it was redone, it should look and feel the same. Any specific reason your asking?
Thanks for the info! I'm asking because I've been working on a course about Editor Customization for quite a while and am trying to gauge how relevant IMGUI will stay for Unity in the future. Basically just checking that no one is getting any crazy ideas about deprecating it... Having now built a few things with UIElements I have to say that I appreciate how much easier it is to build complex things with it, but I find IMGUI is still a great option for building simple things, just because it's so quick and easy to get something going! If you're just building a simple tool for one job that no one else is ever going to see, then the only thing you care about is functionality and then Immediate Mode is the most efficient way to get that done.
Hi col000r, Depending on your course examples, you can still build UI quickly with UIElements. It will not be a 4-3 lines of code-type of thing like some IMGUI examples but you can reuse a lot. So your examples can build off each other. As for IMGUI deprecation, I think it's safe to say the tech will be there for a while still (read: a few major versions). We do however encourage devs to use UIElements by default now. As mentioned previously, we are aware that a few controls and features are still missing and we are progressing towards full parity. We are aiming for parity with UGUI at the same time, adding to the length of the task. Sebastien
I for one am really excited for this to happen. I often want to extend unity's (inspector editors), and I either have to re-create the editor myself or do a big fat hack using GUI.SetNextControlName, which only works if the I want to check for the element. This is the code I use to check if a user edited the text field in a text mesh pro element (and clicked off) Code (CSharp): public override void OnInspectorGUI() { switch (Event.current.type) { case EventType.KeyDown://If it was typed case EventType.MouseDown://If it was copy/pasted case EventType.Repaint: GUI.SetNextControlName("Text"); bool wasSelected = HasSelected; HasSelected = string.Equals(GUI.GetNameOfFocusedControl(), "Text"); if (HasSelected && !wasSelected) { CachedValue = m_TextProp.stringValue; } break; } EditorGUI.BeginChangeCheck(); base.OnInspectorGUI(); if (EditorGUI.EndChangeCheck() && HasSelected) { HasEdited = true; } else if (HasEdited && (!HasSelected || !EditorGUIUtility.editingTextField)) { if (!EditorGUIUtility.editingTextField) { GUI.FocusControl(null); } if (!string.Equals(m_TextProp.stringValue, CachedValue)) { CachedValue = m_TextProp.stringValue; /////////////////~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Debug.Log("The user changed the text); } HasEdited = false; } } imagine how simple it would be if I could register callbacks for fields, like you can in UIElements
Parity w/ UGUI does not mean every feature of UGUI will have its UIE Runtime counterpart (e.g. layout feature in UGUI does not have the same specs as UIE-RT but similar results can be achieved via USS flex, display and other Yoga style properties). With that said, we are hoping for UIE Runtime support at end of year.