Immediate mode GUI-toolkit

It looks a lot like Imgui - https://github.com/ocornut/imgui

How does this one differ?

Looking just at the screenshots, this looks _way_ more powerful/flexible than ocomut's project (which I tried to use in a psersonal project and ended up extremely disappointed with).

The code also looks significantly cleaner. I tried hacking on ocomut's imgui to fix up my complaints and that just drained too much energy to be worthwhile. vurtun's gui.h is ~6000 lines. ocomut's .cpp file is ~12000 lines, and that doesn't include its several headers.

I am a little disappointed to see the silly header-only mistake perpetrated by vurtun's project. Even with the ifdef GUI_IMPLEMENTION, that kind of coding is just sloppy. I don't want to have to recompile every file that uses the public interface just because I changed a private implementation detail, I want faster compilation times (less disk IO, less crap to parse), and I want a header so light that it doesn't even need to be in a PCH (where such a library doesn't belong). Split the public and private code up between a public header and a private implementation source file.

Immediate mode GUIs also tend to be pretty bad for building out important pieces of game editors like property trees. They also usually have problems with animations, transitions, etc. that tend to differentiate good UIs from bad ones. Examples or thoughts on how your library might tackle those problems would be interesting.

Hey,

I wouldn't like to hijack this topic Sean so I'll e-mail you for details about what you think are the issues with my implementation of ImGui.

> Immediate mode GUIs also tend to be pretty bad for building out important pieces of game editors like property trees.

Totally disagreeing with this statement, in fact they are very good at it :)

> They also usually have problems with animations, transitions, etc. that tend to differentiate good UIs from bad ones.

> Examples or thoughts on how your library might tackle those problems would be interesting.

It is correct there is that tendency. I believe it's more of a design choice by the implementer.

I find animation in any *productivity* tool terribly annoying and just non-productive. Animation on an trendy photo filter iOS app is one thing, but you don't want your Maya panels to animate and feel like half of your life is waiting for smooth transitions to happen. So while I agree that they "tend to differentiate good UIs form bad ones", for the sort of debugging, auditing, authoring productivity tools I want to make with an imgui I would say that animation would make the ui worse.

It's really cool that vurtun is pushing on another take at doing imguis!

it does not have any platform window/input management, a render backend or a font library but instead provides simple abstractions for the user to plugin their own implementation.

Finally something in the right direction! I'll give it a try in the near future!

I find animation in any *productivity* tool terribly annoying and just non-productive. Animation on an trendy photo filter iOS app is one thing, but you don't want your Maya panels to animate and feel like half of your life is waiting for smooth transitions to happen.

When I first started with transitions and animations, I added them to everything. It eventually started to annoy me how it felt like it was slower...

My solution is to not animate when you highlight something (or at least one main feature of the UI element shouldn't be animated), but when you leave the UI element, some transition or other animation may occur. This makes it feel better if you move your mouse across many buttons. It feels faster and you can see where you just highlighted.

Perhaps kind of offtopic, sorry about that.

@Glass_Knife

There are a number of differences in design decisions, functionality and support between ocornut's imgui and mine.

First of ocornut's imgui was the inspiration for my imgui and it was the first time I actually heard of the concept, so I greatly appreciate what he has done and is currently doing.

Furthermore he has probably around 10 years more developer experience and better community support than I do and therefore his implementation is probably better suited for non-personal projects.
That being said while I really liked the idea, I wanted something more pure and with more control on my end. So the biggest difference while using his and my implementation is that his library feels to me more like a framework with things running behind my back in the source file and I interact with the system over a number of API calls on the system. In contrast what I wanted was complete control in other words a toolkit were I decide how everything is laid out (memory as well as "widgets") and what part of the library I want to use. There is nothing inherently bad with his approach since it allows for more complex functionality and automation but it is paid for with loss of control.

In general concrete differences are for example that I do not provide a font library which came from another difference in that I do not buffer vertexes and commands, instead I just buffer a basic number of primitive shapes as output. Which depending on what you want can be either a good thing or a bad thing. For example if you do not have a font library already in place and use a graphics library his approach takes away a lot of work you have to do to get the GUI running. But if you already have the functionality you suddenly have duplication which is at best a rise in complexity in the library code.

In addition what I personally like about my implementation is that everything is just a extension. For example if you really wanted you could begin with simple "widgets" without a panel, then go from there and with minimal changes add panel support and then go further to overlapping panels and panel tiling and finally combine both and have quite some powerful functionality.

So if I had to boil down the difference I would say the difference between mine and his is the question of what you want more, control or functionality.

@SeanMiddleditch

First of thanks for your feedback but I don't think that the comparison in code size between ocornut's and my imgui is fair since while I have most of the basic functionality he has a lot more things like font handling, a vector class and a number of other utilities which I leave to the user or do not use. On the other hand I have to admit that I found reading his code to be quite exhausting.

As for the header problem I tried to separate the header part and the implementation part by include guard and GUI_IMPLEMENTAION define and thought that it would remove the need to recompile everything. But if that does not solve the problem than I will definitely divide the library back into a header and source file. Personally I do not have any preference to any of the two approaches so if it causes problem than I see no problem to change it.

Finally to immediate mode GUI's itself. Immediate mode GUI's at its core for me is based around the concept of having a blank panel each frame which can be filled with what ever I want it to be filled with. So while retain mode GUI's have the concept of data structures containing all data needed to present things on screen and the general concept of just creating a new overlapped panel to show content like for example combo boxes, menus or trees provide. I personally think that this is more a result of the limitation of retain mode GUI's to react to changes in the layout so you just create a new overlapping thing to appear and disappear. But the greatest thing in immediate mode is that all changes can be done in place, so the layout of last frame does not exist anymore and if suddenly more space is needed you can allocate it without any problem or even replace things that existed in the the last frame. So while I cannot give you a definite direct answer on the steps you should do to implement a property tree in my library since up to this point did not have to implement that functionality so far, I would say that the core concept of a tree is to hide stuff until needed and then provide it once needed. This is exactly what immediate mode GUI's are good at. I will definitely think about it further and see if I come up with a solution.

As for animation and transitions I don't exactly understand what you mean by that and It would be nice if you could explain to me what it directly is about.

@ocornut

Hey ocornut nice to have the person who was the inspiration comment on my implementation and thanks for your nice words.