Imgui: Immediate Mode Graphical User Interface with minimal dependencies
github.com
github.com
The low # of commits and vague name might be a bad signs, but check the repo description: Developed at Media Molecule and used internally for a title they've shipped, with feedback from domain experts like Casey Muratori. Those two points alone make me pretty excited to try this out.
And a brief explanation of why this matters: IMGUI frameworks are increasingly popular for editors, debugging tools, etc. because they eliminate the need for state synchronization between your 'engine' and the visualization/editing UI. You also avoid the need to duplicate your layout in multiple places - you have one function that is the complete description of your UI. This reduces memory usage and can actually be more performant in many cases because you can easily ensure that you're only ever running code to update visible UI. Things like virtualized infinite scrolling become quite trivial.
Among other places, IMGUI techniques are used aggressively in Unity's editor.
I believe the project was migrated to github recently, but it has been around for awhile.
http://docs.unity3d.com/Manual/editor-PropertyDrawers.html
Not sure how much they use it elsewhere, though. It's possible they phased out the other uses.
http://issuetracker.unity3d.com/product/unity/issues?categor...
I read somewhere that the plan was to migrate away from it, a long time ago (2/3 years back?), so perhaps they just decided not to.
http://blogs.unity3d.com/2014/05/28/overview-of-the-new-ui-s...
Differences include that the other imgui is licensed under the zlib license and targets only OpenGL 3.2. Also it appears to be older. And is the first google hit for imgui...
I can understand that it's an advantage to have something like this renderer-agnostic, and embeddable anywhere in your render flow, but the way you have to use this completely defeats its purpose IMO. I would love a higher-level abstraction layer on top of this that deals with all the render state setup, so I only have to setup the UI itself and populate it, and can throw in a one-liner somewhere in my render function that draws it. In this case, I would happily trade the fact that this would break render-independence and would clobber render state, for ease of integration.
That said, the end result looks immensely useful and very-well done, it's just too involved to setup and use I think...
Thanks for your feedback (I am the author).
The example applications probably haven't received enough love. They are standalone apps and there is only so much you can shrink the code. If you are using your own engine it is likely that you've already done initialisation and you have helpers to load shaders easily.
Imgui.cpp/Imgui.h themselves are render agnostic to enable portability on embedded systems and consoles where OpenGL is unavailable so it is important it stays this way. However it is perfectly possible that we could rework the sample applications to become more like "drop-in" for a given architecture (OpenGL+glfw coming to mind as being a common case).
It also appears that I could make the OpenGL sample simplier by using the fixed function pipeline and the glScissor() function so I will try that.
This is a first release and it hasn't been used or touched by more than half a dozen people so it may take a few patches until I can make the sample application simpler.
Best. O.
A stripped-down minimal example would be very helpful to show how to use the library, just a simple popover with a single control and the absolute minimum required render calls for example. I agree that the fact that this is render-agnostic by the way, and like you mentioned yourself: if you need this you probably have most of the initialisation and shader compilation stuff covered, I wrote some simple wrapper classes for ES2 myself. But a really thin OpenGL (ES) or DirectX specific layer on top of the core functionality would also be great to make the tool a little more accessible of course ;-)
Great work nonetheless, maybe I'll play around with it anyway to see how much work it actually is to embed this in my (at this stage extremely bare-bones) renderer.
I will provide an example app that use glScissor() and the fixed pipeline so no custom shaders will be required. However I am not sure how the performance will behave with widgets that frequently change the clipping rectangle. At the moment the system is optimised to minimize draw calls (I would like a typical "complex" tool to take under 0.5/1.0 milliseconds to build and render). I was actually considering moving the clipping rectangle within the vertex buffer so everything could be rendered in 1 draw call, which would simplify the code and be faster, but requires a custom shader. That is to say, it is an open ended problem and there's not one single solution.
I already pushed some tweaks and comments in the sample applications. Your criticism is perfectly legit and I aiming to simplify integration as much as possible so please don't hesitate to comment further if you had another go at it.
See https://github.com/djoshea/imgui/blob/master/examples/opengl...
brew install glew
brew install glfw3
cd examples/opengl_example/
make
./mainhttp://research.microsoft.com/apps/pubs/default.aspx?id=1892...
Frameworks like React take a very indirect approach, when it turns out that the immediate simple approach might be more viable.
For some reason, I'm getting downvotes even though my enthusiasm was genuine. The mystery of hackernews.
I didn't downvote you, but your initial post set off my snark-o-meter.
You do need some better way of navigating round the file than search, though! I recommend something like visual assist or imenu.
None of my other tools care about file length - it might actually take longer to build if the code were multiple files since most of the processing overhead will be in invoking the process and the context switching between the make tool and the compiler - modern C/C++ compilers can handle 10kloc files in their sleep.
In fact, in many projects that I've done with "correctly split" source files (one per class/object impl), I've seen that often the license and the general file boilerplate is actually longer than the code that goes in that file. It actually costs more for the compiler to handle this case, as it is doing even more useless I/O.
Just curious ...
1. get the screen height 2. draw a block with ascii art with that height. 3. when done put height*line breaks to clean the screen.
or do you want something to handle termcap for you? `dialog` i think does that
So TIOCGWINSZ for the dimensions. And printf("\033[7m") to get a background for the box (you can use colors too, though I think they're mostly fugly). printf("\033[2J") to clean the screen.
https://en.wikipedia.org/wiki/ANSI_escape_sequence
Using an API wrapping the database of terminal incompatibility might've been a good idea in the days of hardwired glass terminals. But nowadays it can cause more problems than it solves, plus it's ugly as hell. Also, we now have standards and emulators to rely on for when you can't otherwise adapt.
Try get to your shell on an older Solaris box connecting via rxvt-unicode. Oh, missing a terminfo entry? That's easy (if you know how to add it, as a user). But, wait, the name of the terminal is too long! So all applications which rely on curses or term(info|crap) will give you grief. Even though all terminals (terminal emulators really) people use these days support a reasonable subset of the ANSI escape codes -- and when they don't, you can run something like GNU screen between your terminal and the application. Things would just work if applications assumed a standard and didn't rely on a huge database and thousands of lines of code to deal with it.
ImgUI is a very nice engineering feat, but it's not terribly practical.
>ImGui is designed to allow programmers to create "content creation" or "debug" tools (as opposed to tools for the average end-user). It favors simplicity and thus lacks certain features normally found in more high-level libraries, such as string localisation.
On my laptop, xterms (with my custom colors) are the closest thing to native look, since they're what I look at 80% of the time, and they ship with the OS. I'm happy that applications which need more advanced graphical features do not attempt to look and feel like xterm.