- 114comments
- 31comments
- 19comments
- 422comments
- 176comments
- 47comments
- 11comments
- 91comments
- 533comments
- 26comments
- 12comments
- 105comments
- 1comments
- 185comments
- 126comments
- 33comments
- 300comments
- 360comments
- 23comments
- 18comments
- 8comments
- 89comments
- 23comments
- 47comments
- 4comments
- 44comments
- 122comments
- 278comments
- 7comments
- 119comments
What is better than using React's one-way reactive dataflow? Well, just run everything in a continuous loop!
IMGUI techniques don't even require running a continuous loop... you can use them in an app that responds to mousemove/mousedown and only paints when necessary.
Yep, I've been following this work for awhile now. You can also do much better than that with incremental execution. See:
http://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.
It totally read like typical HN 'didn't read the article' downvote snark, especially since it seemed to be comparing it against a javascript MVC framework. I apologize for downvoting it. :-(
I guess it sounds so simple that it sounds like snark. I should have been more detailed, but I decided to throw my two cents in a bit early.
Hm. How does React take a more indirect approach than the approach in this paper? Reading the code examples it seems to use callbacks (and thus events) for handling clicks and taps.
Other than the REALLY inadvisable name choice (good luck getting precise search results for the term IMGUI now...), this looks great.
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.
Was used in Unity's editor, I don't think that this is the case today.
I believe the project was migrated to github recently, but it has been around for awhile.
Still used in Unity for property drawers:
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.
Hmm...It seems that at least they still are using it:
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.
Oh they're definitely migrating away from it, because it was pretty terrible. Whether it was terrible because it was a bad implementation, or because it was a bad idea, or because Unity is an editing tool and its users expect a more "retained mode" approach that enables them to build UIs without writing code, is an interesting discussion, but Unity is through with immediate mode UIs, and trying to bury it. Their new stuff is very nice, and leverages many things about Unity's editor and graphical capabilities, but it's certainly not minimal.
http://blogs.unity3d.com/2014/05/28/overview-of-the-new-ui-s...
Interesting, thanks for sharing! I think immediate mode done right could be very liberating, but it requires some more work to get there.
I realized after putting this on GitHub that the name is a bit ill-advised considering ImGui is a concept and I am merely providing an implementation here. I will have to think up of a name. Any suggestions?
imgui is kind of catchy.. but alas, there is another project with the same name (which also stands for "immediate mode graphical user interface"), same purpose, written in the same programming language, and also hosted on github!
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...
https://github.com/AdrienHerubel/imgui
The last time we talked about IMGUI, for historical reference:
https://news.ycombinator.com/item?id=4201748
Well, if there is an award for the library name that is hardest to get Google results for this one is a contender.
People keep saying that in this thread but I don't see why. It's a unique enough name, and the entire first page of results is relevant. What's so bad?
It's actually showing for me as the first result in Google search, which is even better than simply appearing somewhere down the page.
It's like naming your new Model-View-Controller library simply "MVC". Ok if you're the one who first came up with MVC, less so if it's already a well-established term. Yes, all the results in that first page of results is relevant. But the results aren't relevant because they're referring to this library. Instead the library is co-opting the term that all of those search results are referring to.
Not to state the obvious, but there are very few types of desktop programs where not having a native look and feel is OK. Especially when UI looks as unique as ImgUI does. Games, demos and, perhaps larger application software, like Blender, that are meant for prolonged continuous use and that run full-screen.
ImgUI is a very nice engineering feat, but it's not terribly practical.
It's sold and presented as an engineering tool. Why does something simple that only the developers are supposed to see need UI chrome bloat on top of it?
Yet there are systems on which "native look and feel" is not even a thing, because they are not wed to a particular toolkit or theme.
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.
This looks sweet, but 6KLoC file. How do you even do that and stay sane?
I frequently see such long files when looking at typical C or C++ projects, actually both closed and open source. Most other languages seem to have unwritten laws that source files shouldn't be larger than 500 LOCs.
Provided you avoid globals, the sky's the limit. My professional record is 17,000 lines; after a while it became a game, to see how far we could take it before somebody cracked. But in the end the project finished before anybody felt the need to split it up. It was actually very easy to keep on top of and handy to have everything in one place.
You do need some better way of navigating round the file than search, though! I recommend something like visual assist or imenu.
Haha, sounds like fun
I don't see why people have such a problem with long source files to be completely honest. I'd rather do refactoring in one source file than edit 10 and wonder if I hit them all.
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.
I was totally sold on this and already preparing to try this out on a simple game using OpenGL I'm working on as a pet project, until I saw the code examples. The amount of highly-specific OpenGL code that's apparently needed to embed an ImgUI popover is completely prohibitive to my use case, the GLEW and GLFW examples literally have 3 times the number of OpenGL calls my own rendering function has, I see custom shaders used just for the UI, setting up clipping rectangles, loading font textures, etc. And that's just to manage renderer state, not even to setup the popover itself.
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...
Hello,
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.
Thanks for the explanation :-)
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.
The thing with how rendering work is that a "complex UI" vs a "single control" will use the same and only rendering feature required, aka: "render triangle list given a scissoring rectangle". There's no middle ground.
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.
If you update to latest I have reworked the OpenGL sample to now use the fixed-pipeline. It is a little less efficient but simplier to understand.
Thanks, maybe I'll have a look this weekend if I can find some time, and let you know how I fare. I don't think I can actually use the simplified version though, as I'm using OpenGL ES 2.0, but I should be able to figure it out I think :-)
Is there an equivalent tool for ncurses ?
Just curious ...
Or just for ANSI-capable terminals, without involving any cursing and terminfo/termcrap nightmares.
what you ask is impossible. unless you do:
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
I said ANSI-capable. I also assumed the terminal dimensions are either fixed or can be retrieved somehow, e.g. from the environment or via an ioctl like in Unixy systems.
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.
This is why I like FRP. It is like the perfect combination of imguis and normal guis. Just treat all events as time varying values and you're basically just writing imgui code.
(How) does this compare to AntTweakBar?
I managed to get this building on MacOS Mavericks using the glew and glfw3 libraries off of homebrew. I forked it at djoshea/imgui
See https://github.com/djoshea/imgui/blob/master/examples/opengl...