@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.