I think I understand how it all works now, after playing around with it for a while. But one thing still bothers me. Which suggests I might be missing the point.
When compared to the old gui system, the only advantage I can see is that we can position things easily on screen, but everything else is extremely inconvenient. Let me illustrate one situation. I have a slider and a text field, both intended to represent a float used in my application. You can either use the slider or type a number in the field, and the other will change to reflect. In the old system this is simple to achieve, as all I have to do is (let’s forget about casting details) myfloat = guilayout.textfield(myfloat); myfloat = guilayout.horizontalslider(myfloat). There you have it, everything updates nicely. In order to have something like that with the new UI I would need to keep all elements in a central script and update them manually inside Update or have some clever code using the event. But doesn’t this defeat the purpose?
Anyway, I started working on a non-game project and I already have a working UI using imgui. At the same time I work on the bulk of the application I started to work on parallel on a UI with the new system, hoping it would advance faster than the application part, so I could continue developing everything together using the new UI. Unfortunately the main application parts are almost done and the new UI is still stagnated, so I’m prepared to move forward with the old UI system, since it seems so much easier and convenient. But it pains me to think I’ll eventually GET the new UI and changing it all to the new system will be a pain.
I haven’t really used the old system, but how would you have changed the size/color/images of your controls?
If you wanted to have a panel with a bunch of controls inside of it, and then you wanted the entire panel to change size/shape/location during runtime, how would you have handled that? Could you have created animations for that panel using Mechanim?
How about a scrollable window containing a bunch of UI elements?
My guess would be that the old system is pretty easy if you just want the default implementation of a simple case, but probably doesn’t scale up as well to handle more complexity or customization. This is a typical tradeoff in designing tools: in order to handle wider variety or higher complexity of tasks, the tool has to have more built-in overhead, which makes it slower for very simple tasks.
The new UI also makes it possible to do a fair amount without any scripting at all, which could be valuable if not everyone on your project is a programmer.
Most visual effects are very difficult to achieve with the old system. If not impossible, impracticable. But scrollable window with a bunch of ui elements is pretty easy. In fact, I have an array with floats, each get its own slider, so I made a window with a scrollable area containing as many sliders as I want. All in less than 10 lines of code, with a for loop and a couple of guilayout commands to start scrollable area. You can even change the number of sliders in real time. The thing is, I know I can recover that kind of functionality with the new UI but it’s not nearly as simple.
I would like to make the UI look pretty and stylish but, if that’s really the main advantage the new system can offer me on this particular project, I’ll stick with imgui for now. I emphasized “on this particular project” because I understand the many uses of this system in many other scenarios that are not applicable to my non-game application. Maybe after the application is done and fully working I’ll slowly start implementing it all under the new system. In fact, I think that’s what imgui is made for. Quick prototyping. It gets the job done easier and faster, if you don’t mind the lack of control over visual elements.
Building a prototype in a simple system you are familiar with rather than a more complex system that you are less familiar with is a totally defensible choice.