17 ms·

Dear ImGui – Bloat-free graphical user interface library for C++

284 points by dragonsh 6y ago

ZenPsycho 6y ago
until accessibility is implemented, don’t use this please
- minerjoe 6y ago
  Is this truly what you want? We're developers, I'd think a call out to help bring in a11y would be better recieved.
  - ratww 6y ago
    The problem is that accessibility APIs are very limited and stagnated in every single OS (except maybe Apple). For basic default widgets accessibility works out-of-the-box, but as soon as you want to do something more complex or do custom drawing like Dear ImGui does, you're forced to write WAY more code than anticipated. In Windows, for example, you need significantly more code to get a11y than to draw a custom widget. If you're drawing to a framebuffer like Dear ImGui is doing, it's even worse. In some OSs have to use other APIs (like focus management) to take advantage of the a11y APIs, which is kind of "at odds" with the whole immediate-GUI paradigm. This is amazing new for corporation-backed products like Flutter, React Native or even Qt, because it makes the barriers to entry way higher. On the other hand, open source project will lack the resources to do proper native a11y. Asking OS vendors to have proper accessibility in their OSs is IMO the more appropriate step for accessibility advocates, rather than forcing dozens of Open Source projects to reimplement the same thing over and over.
    - mwcampbell 6y ago
      > Asking OS vendors to have proper accessibility in their OSs is IMO the more appropriate step for accessibility advocates What more should OS vendors do? Is there anything OS vendors could do that would actually help the state of accessibility in fringe GUI toolkits like Dear ImGui? This isn't a rhetorical question. In addition to being an outspoken accessibility advocate on threads like this one, I'm currently a developer on the Windows accessibility team at Microsoft, which owns the UI Automation API among other things, and I want to know what more we should be doing.
      - ocornut 6y ago
        Hello Matt, For a small developer I believe the whole topic seems quite overwhelming. To attract fringe GUI toolkits it would be useful to provide easy-to-chew accessibility samples based over 3d graphics technology (say: take a DirectX11 samples drawing a few text and buttons and make it accessibility compliant).
        mwcampbell 6y ago
        That's a fair request. All of the full-featured accessibility implementations are buried in complex UI frameworks and browser engines. I'm also aware that the sample UIA provider implementations in the Windows SDK aren't very useful; they all implement a single control in its own HWND, using GDI or GDI+. As part of Microsoft's Hack for Good program, I worked with the developers of the Quorum language and development environment (https://quorumlanguage.com/ https://quorumlanguage.com/) on their UIA implementation. So I know how frustrating it can be for a non-expert to implement UIA, and how easy it is to get it wrong. I'll have to see what I can do about implementing a better sample.
        ratww 6y ago
        Just better documentation, tutorials and samples would improve the situation 100x! The current ones are hard even for veteran native programmers. Next thing I'd love to see would be a simplified API to allow smaller developers to also use it. As it is, only giant companies can afford handling accessibility. A personal wish would be to have an immediate mode imperative API for accessibility that abstracts the Automation Tree. Similar to how Dear ImGui does. Something like: BeginFrame, TextInput, Checkbox, EndFrame, etc... plus some commands to "ask" if the Automation API wants to do something, like moving to the next control. Maybe a Dear ImAccessibility? This would work perfectly for Video Games and would allow accessibility to added even to games that didn't predict it. Games are pretty simple, and don't require too much variety. I worked in an Adventure Game in the past and it would be 100% playable using A11y with something like that. I would love to make a 100% accessible game in the future. This of course could be a simple multi-platform wrapper instead of something from your team.
        6y ago
- mcdevilkiller 6y ago
  Until you understand the objective of the project, don't comment please
  - ocornut 6y ago
    I think ZenPsycho is right calling out for accessibility features. It's unfortunate that most low-key UI libraries don't support them, partly because those OS API are so complex and for a non-user it is hard to understand them (much like for English users it is sometimes hard to understand what's needed for localization). A pragmatic way to see it - and arguably it's an issue I don't have answer for - is that the sum of all desirable modern features (incl. but not limited to accessibility features) are growing the scope so complex and large it is also - very unfortunately - hindering innovation. Everyone agrees accessibility features are desirable. Yet if every experimental or hobbyist project needed to implement all accessibility features, those projects wouldn't exist. So two steps forward is costing us one step back here :(. There are _so many things_ dear imgui doesn't do at this point, it can't handle full internationalization and right-to-left text. Maybe it'll catch up. Maybe other solutions will solve this. For now as I don't have the resources to do it all myself. But the more people use and work with a given software the more likely it is to evolve and improve. I would gladly surrender to a much better product than dear imgui that implemented this while also solving the problems dear imgui aims to solve.
    - mcdevilkiller 6y ago
      This is a library for building internal tools, debug GUIs etc. This is not Qt/GTK, or React, or a CSS framework.
      - ocornut 6y ago
        Where do you draw the line? Some companies are using it for polished large tooling which may have thousands of end-users. Those users will eventually want a solution to tackle that.
      - kevingadd 6y ago
        Any internal tool or debug GUI has reasonable odds of becoming a user-facing tool eventually, and it's a matter of time until you end up needing to support staff/customers in territories with RTL languages or ideographic character sets. At that point, you end up regretting most of the corners you cut. I built lots of internal developer tools for a mid-sized western studio and it wasn't long until I had to go back and patch in a bunch of localization support because it turned out the publishers overseas needed to be able to use it and not all of their staff spoke English. Any blind employees were probably completely out of luck (maybe not, I did use Win32.)
Torkel 6y ago
Happy to see ImGui trend here on HN! It is an amazing tool that is used in a lot of game engines for making internal/dev gui:s. The principle of drawing gui "as you go", interleaved with control flow makes it easier+faster to make gui:s. In our company's main app we use ImGui (with customizations) for all gui work (from C++ and Rust).
- gambiting 6y ago
  I work at one of the largest games publishers out there and I'm pretty sure ImGUI is integrated into all of our games at this point during development for debugging. It's an absolutely fantastic tool. Oh, we do actually sponsor it: https://montreal.ubisoft.com/en/ubisoft-sponsors-user-interface-library-for-c-dear-imgui/ https://montreal.ubisoft.com/en/ubisoft-sponsors-user-interf...
  - Torkel 6y ago
    Nice :) Will you use it for user-facing gui:s, looking forward?
    - gambiting 6y ago
      Very unlikely, I don't really see why we would. All of our engines have their own extensive UI tools that can be used to create rudimentary interface very quickly if needed. Maybe if we ever released like a level editor or something, but I'm not aware of any such thing right now.
    - greggman3 6y ago
      As much as I love Dear ImGUI it's arguably not a good UI for user-facing apps (vs dev team apps) Supporting all of unicode, all IMEs, emoji, right-to-left languages, etc. is arguably out of scope for Dear ImGUI.
      - Torkel 6y ago
        Well, maybe. We use it user-facing for suite of niche vr/tele-op applications and it works wonderfully. We have support for Korean, Japanese, Hebrew (serious issues with right-to-left in our implementation though). The thing about ImGui is it puts devs on steroids - adding gui is just sooo fast. And fun. And easy to tweak. And easy to debug. 10X, maybe? I get that for a game maybe the user facing gui is less of an issue - it needs to be really polished and maybe there isn't as "much" gui anyway? But for indie-games and productivity apps, it seems like having a gui option that offers 10X faster development - wouldn't that be really convincing? Even if it isn't 10X, maybe only 1.3X, it still seems like it would be easy to motivate some missing functionality. And I would argue it is way more than 1.3. And looking forward - IME, emoji, right-to-left: those are just PR:s waiting to be written :) I'm incredibly bullish on ImGui paradigm. If programmers gravitate towards it and prefer it as much as they do then there is some real power there. The only bad thing about ImGui is that the Rust port of it... well... sucks. At least the way it handles strings at the moment. Then again I always found Rust's handling of strings to be one of the negatives of that language.
dasloop 6y ago
The widget should keep its state private. ImGui::InputText("string", buf, IM_ARRAYSIZE(buf)); ImGui::SliderFloat("float", &f, 0.0f, 1.0f); And maybe is a C++ lib but the interface is C with namespaces. Odd.
- perfunctory 6y ago
  The way I understand it, the idea is that widgets don't own the state. They are sort of stateless. Your app owns the state.
  - formerly_proven 6y ago
    Exactly, the app owning (most of) the state is precisely the point of ImGui.
- Toenex 6y ago
  Immediate mode is a stateless design pattern.
- Cloudef 6y ago
  Public interface with C makes sense. C++ doesn't have portable ABI plus it makes porting harder.
perfunctory 6y ago
I like ideas behind immediate mode gui. It's a bit like React.js only without DOM in between. It's not ideal, it has its own issues, but it could develop further into something more robust, I hope. GUI is hard.
roytries 6y ago
Not sure why this is showing up on HN today. But Dear ImGui is absolutely amazing. And its not just for C++. I use it myself in my C# game engine. (There's a C# port that uses System.Numerics: https://github.com/mellinoe/ImGui.NET https://github.com/mellinoe/ImGui.NET) which I've ported to MonoGame https://github.com/roy-t/ImGui.NET https://github.com/roy-t/ImGui.NET) I've used a lot of different UI frameworks (winforms, WPF, Html/CSS based frameworks, custom game engine frameworks). But for prototyping Dear ImGui and the whole immediate GUI idea is amazing. It even looks quite decent and the new docking support is great :).
- flohofwoe 6y ago
  The Dear ImGui C++ API also maps very well to C, so well that I actually prefer the C-API when working on a project that's mostly C (instead of using C++ for the UI code and C for everything else as I did before). AFAIK most of the other language bindings are also based on the C-API (which is autogenerated from the C++ API): https://github.com/cimgui/cimgui https://github.com/cimgui/cimgui
- mholub 6y ago
  We recently started to use Dear ImGUI in our custom game engine. Before we used Unity which has its own immediate mode gui solution. And I have hard time to switch. I don't know if I don't understand how Dear ImGui work yet in comparison to Unity's one but it feels so limited. So main difference is that Unity is multipass (it calls your gui drawing code multiple times per frame) and because of it it supports horizontal layout, vertical layout, custom layout modifiers, styles and it is easy to use in Dear ImGUI I am struggling to write stuff like: layout 3 controls horizontally, allocate fixed size for first and last one and use all left space for middle one or layout next N controls vertically of unknown height and use this background color for them, then layout another set of controls and use different background style for them I am not the person who was actively working on integration it into our engine, so maybe it's the problem of not having documentation on our wrapper...or me not understanding very basics of it
  - uryga 6y ago
    honestly, im pretty sure imgui can't help you here, i.e. you have to calculate all the necessary sizes/positions yourself and tell imgui where everything should be
prvc 6y ago
>This library is called Dear ImGui. Please refer to it as Dear ImGui (not ImGui, not IMGUI). >(The library misleadingly started its life in 2014 as "ImGui" due to the fact that I didn't give it a proper name when when I released 1.0, and had no particular expectation that it would take off. However, the term IMGUI (immediate-mode graphical user interface) was coined before and is being used in variety of other situations e.g. Unity uses it own implementation of the IMGUI paradigm. To reduce the ambiguity without affecting existing code bases, I have decided in December 2015 a fully qualified name "Dear ImGui" for this library. Yes, but why "Dear"? Makes it read in an odd way wrt to idiomatic English.
- ejolto 6y ago
  the owner is french, I bet the french "cher imgui" reads better.
  - app4soft 6y ago
    > the owner is french Think, for #dearMoon[0] name "dear" refers to Jules Verne's "Rocket to the Moon".[1] [0] https://twitter.com/dearmoonproject https://twitter.com/dearmoonproject [1] https://en.wikipedia.org/wiki/Jules_Verne%27s_Rocket_to_the_Moon https://en.wikipedia.org/wiki/Jules_Verne%27s_Rocket_to_the_...
  - delroth 6y ago
    No, it does not.
- amelius 6y ago
  > Yes, but why "Dear"? Makes it read in an odd way wrt to idiomatic English. And "ImGui" does not?
- reyqn 6y ago
  I would guess, since it has been rebranded on christmas day, that it's named Dear ImGui because when you would write a letter to Santa Claus, you would start by "Dear Santa" (or at least in french, "Cher père Noël"). Maybe a parallel is to be made between the library and Santa Claus, because if you ask for something kindly, you would magically have it, without it being cumbersome for you.
database_lost 6y ago
I don't work that much with GUI applications, but Dear ImGui was perfect for a past project and I just wanted to chime in on the positive feedback :) Take care everyone!
srikz 6y ago
Dear ImGui is excellent and is very handy to make GUI version of a CLI app especially if we want to interactively set values and see results. It is fairly low level (deliberately) and that’s great to keep it simple. I wish there is a standalone GUI ‘framework’ which builds on these primitives and leans on standard library to make the experience a bit more nicer when building standalone applications. I understand this is not the goal of Dear ImGui. I may give it a shot in a few months time if I don’t come across any such project.
pansa2 6y ago
Qt seems to be the most popular library for cross-platform GUI apps written in C++. Is Dear ImGui a credible alternative? How does Dear ImGui compare to Qt?
- gambiting 6y ago
  Well, these are as different as it gets. Dear ImGui is purely code based and it's drawing in immediate mode. Meaning there is no way to have a visual tool to arrange layouts for things, you have to do everything in code. It's fantastic for debugging, prototyping, very simple interfaces when that's all that's required, but it's not a fully fledged UI library like QT. It's like comparing a bicycle to a 4x4. Sure a bicycle works better in some uses cases, but for it's not designed for heavy lifting.
  - formerly_proven 6y ago
    ImGui is not drawing in immediate mode (which isn't supported any more in any contemporary accelerated graphics API). Only the API is immediate mode. You can Begin() the same window multiple times and each time you do it during a frame you keep appending to the same window.
    - gambiting 6y ago
      Well yes, sorry, I misspoke.
    - flohofwoe 6y ago
      This point is so important that it bears repeating: only the programming model is "immediate", not the implementation under the hood. Dear ImGui keeps (internal) state around between frames, maybe not as much as other UI frameworks, but it does. Especially the rendering isn't "immediate mode", the UI isn't rendered while running the code that's building the API. Instead Dear ImGui builds a "deferred mode" rendering command list which is actually very efficient in terms of required draw calls. The main difference to traditional UI frameworks is that there are no different code paths for UI creation, UI updating, and handling input. Instead all those things are happening in the same sequential code flow.
modeless 6y ago
One of the most valuable parts of Dear Imgui is the example applications, which are great as a reference and starting point for your own projects. Many different platforms and rendering APIs are covered. Also be sure to check out the 'docking' branch, which implements docking panels and tearaway windows in the style of Visual Studio. There are many low quality versions of this concept in other GUI libraries but I think Dear Imgui's version is the best I've seen outside of Visual Studio itself.
amelius 6y ago
Does it support GPUs and Wayland directly?
- flohofwoe 6y ago
  ImGui itself doesn't have its own renderer, it just provides a list of simple rendering commands which then must be rendered by your own code (the git repo comes with ready-to-use example renderers using any of the standard 3D-APIs, GL, D3D, Metal, Vulkan, etc...). That way it's easy to integrate into existing code bases and portable to all sorts of "exotic" platforms (for instance game consoles - which generally don't have "standard" APIs).
MaxBarraclough 6y ago
I'm reminded a little of the FOX Toolkit, [0] but ImGui has more of an emphasis on accelerated graphics. [0] http://fox-toolkit.org/ http://fox-toolkit.org/
- CyberDildonics 6y ago
  How are these similar in any way except for being GUI libraries?
  - fao_ 6y ago
    > How are these similar in any way except for being GUI libraries? They didn't say it was similar, they said imgui reminded them of it.
app4soft 6y ago
Is there usable Dear ImGui fork/sample for OpenGL 1.x?
- formerly_proven 6y ago
  Putting the "immediate" back in "ImGui".
- flohofwoe 6y ago
  It's definitely possible but I guess nobody has done it yet because the usual GL "baseline" version these days is GLES2 (and that mostly because of WebGL). Each rendering command you get back from Dear ImGui comes with a block of vertices and indices. Typically those are stashed into 3D-API vertex- and index-buffers for efficient rendering, but they can just as well be "unrolled" to glBegin/End calls, it's just not as efficient. With a good GL driver this probably doesn't matter much though.
- greggman3 6y ago
  All Dear ImGUI does is generate arrays of vertices + texture coordinates. That's it. It doesn't support any particular graphics API. There are examples in the repo but they are just that, examples. If you want to use it in OpenGL 1.0 it shouldn't take you more than a few minutes.
  - account42 6y ago
    It definitely does come with backends for various APIs: https://github.com/ocornut/imgui/tree/master/backends https://github.com/ocornut/imgui/tree/master/backends
    - app4soft 6y ago
      > It definitely does come with backends for various APIs: And there are NO imgui_impl_opengl1.cpp & imgui_impl_opengl1.h, only next: ... imgui_impl_opengl2.cpp imgui_impl_opengl2.h imgui_impl_opengl3.cpp imgui_impl_opengl3.h ... UPD: Some say[0] that imgui_impl_opengl2.cpp really is imgui_impl_opengl1.cpp: > imgui_impl_opengl2.cpp is actually misnamed and should be imgui_impl_opengl1.cpp. [0] https://discourse.dearimgui.org/t/missing-glactivetexture-call/409 https://discourse.dearimgui.org/t/missing-glactivetexture-ca...
exDM69 6y ago
As much as I like Dear ImGui, the immediate mode paradigm doesn't work everywhere. The problem of "page tearing" (not to be confused with vsync) means you either need to render frames continuously, or at least 2 frames for every time you get input or need to implement some kind of "retained mode state tracking" on top of Imgui. It's good for games, but for applications where you're not rendering new frames constantly, the paradigm doesn't seem a very good fit. I wish there was a retained mode GUI library that would be as easy to integrate in your game and graphics apps as ImGui (or nuklear) is. On my spare time, I've been working on a retained mode GUI layout and rendering framework (not a complete GUI toolkit) that uses a DOM-like tree, CSS style flexbox layouts and produces a vertex buffer for rendering like ImGui does. Unfortunately life gets in the way, and all I have to show for my project is a small prototype in C and another one in Rust (can't decide which I like more) that draws some text and rectangles with a fancy layout. Code is not public at the moment but I'm willing to share it with anyone (on GitHub) who responds with a thoughtful comment or a good question. I have been following Raph Levien's fantastic work on Druid and Rust GUIs which has been very inspirational, this video in particular [0]. Where Raph is focused on native GUI rendering and high fidelity text output, I've only focused on rendering in a GPU application using shaders and only very basic text layout with simple kerning (like Dear ImGui). As Raph points out in his later talks on the topic, layout and rendering are only half of the GUI puzzle. The other half is maintaining the state of the application, usually through some kind of widget tree. Leave a comment if you're interested, I'd be happy to chat even though it doesn't seem like my projects are going anywhere anytime soon. [0] https://www.youtube.com/watch?v=4YTfxresvS8 https://www.youtube.com/watch?v=4YTfxresvS8 Data Oriented GUI in Rust by Raph Levien
- flohofwoe 6y ago
  Wouldn't it be possible to separate the public API from the internal implementation so much that the library appears "immediate mode" on the outside, but is completely "retained mode" on the inside? With a persistent widget tree which is only manipulated by diffing it against the current frame's UI description provided by the user code? The important feature of immediate mode UIs is that there's only one sequential piece of code for UI creation, updating and input handling. All I'm saying as the framework user is basically "this is what I want the UI to look like in the current frame". E.g. if the UI that's described in the current frame by user code is completely identical to the last frame's UI, exactly "nothing" would happen, the internal widget tree wouldn't change, and nothing would be rendered.
andybak 6y ago
I haven't properly thought this through but is here a sense in which the React "one way data flow" paradigm is a case of rediscovering immediate mode GUIs on the web?
- flohofwoe 6y ago
  IMHO there's a lot of overlap between the reactive UI philosophy and the immediate mode UI philosophy. The main difference is IMHO that React is "mainly data" while IMGUI is "mainly code". But code is data and data is code, so... :)
- gauchojs 6y ago
  I love it until I have to do modals..
hartmel 6y ago
- the developer is the creator of MEKA, a (1998!) Sega Master System emulator, which had the reputation to be the best during a long time (and still may be, I don't know anymore) - WonderBoy Dragon's Trap remake and Street Of Rage 4 for PC/consoles, it's him too I may be wrong, but following the screenshots, the Dragon's Trap development was like : we need tools to write a game ! let's write it ! Wait we need libraries to write tools ! let's write them ! The quality of the game and all the details reflect impressive skills and amount of work.
ahaferburg 6y ago
Every couple months I browse the screenshot threads https://github.com/ocornut/imgui/issues/3488 https://github.com/ocornut/imgui/issues/3488 Looking at them makes me really happy for some reason.
- malkia 6y ago
  Agreed. These look fantastic, and has been the driving force for folks around here to want to change to that. I just don't know what to expect once we go that route (certainly intrigued, also occurnut is one of the nicest and most responsive people around). We have large 3d level editor, and there has been talks about us trying imgui with it. Slowly moving it out of Qt maybe? There is lot to like now in imgui - especially now that there is proper docking :)
enriquto 6y ago
Widgets are bloat. Is there a similar library but without widgets? Something really, really simple. I just want a canvas to draw, and a handler to receive mouse and keyboard events. No windows, no text, just a framebuffer. Back in the day I was really happy with glut and opengl. You just took the three-line hello world and started drawing stuff without fuss. ImGui seems too unnecessarily complicated for me.
- flohofwoe 6y ago
  Shameless plug, but check out the Sokol libraries (there's also a header with a Dear ImGui rendering backend sitting on top of sokol_app.h and sokol_gfx.h): https://github.com/floooh/sokol https://github.com/floooh/sokol ...and here's a minimal standalone starter project for writing Dear ImGui apps in C I just created a couple of days ago: https://github.com/floooh/cimgui-sokol-starterkit https://github.com/floooh/cimgui-sokol-starterkit
  - enriquto 6y ago
    I love this! I'm currently using my own shit headers, but this stuff is really appropriate. Thanks!
  - prime31 6y ago
    ...and here is a slightly more rich starter project that happens to use Sokol + Dear ImGui. It was made to create game tools fast in Zig. https://github.com/prime31/zig-upaya https://github.com/prime31/zig-upaya
- pkphilip 6y ago
  You can already directly draw using framebuffers etc. However, you will likely end up re-implementing widgets in any case, if your app gets more sophisticated. About UI, it is not necessary that it should be heavy and bloated. Lazarus IDE, for instance, produces very small binaries even for fairly sophisticated UIs and it is quite fast.
  - enriquto 6y ago
dgr582systems 6y ago
Dear ImGui is so easy to get working compared to other similar C++ libraries. For small dev teams using C++ that alone makes it super valuable. I hate losing a day to figure out how to link in some crazy, clashing dependencies. Never had that problem with this library.
- FullyFunctional 6y ago
  Over decades, I had developed an almost not-invented-here attitude exact because dependencies are always such a pita (oh Python hell) and drag in a lot of bloat. Rust is the first language I have used where external dependencies (from crates.io) Just Works(TM). However they can still drag in bloat :)
sime2009 6y ago
Visually it doesn't look so good out of the box. Are there some extra styles or libraries etc out there which implement good looking styles on top of Dear ImGui? Or are dev expected to put their own style on top of it?
- skocznymroczny 6y ago
  Usually it's used for debug interface in game engines, it's not really meant for full-fledged applications (although you could use it for that usecase).
- JabavuAdams 6y ago
  It looks good compared to the hand-rolled debug GUIs that game developers often implement themselves on top of OpenGL. But, yeah.
JabavuAdams 6y ago
IMGUI is good on many levels, but also has some serious drawbacks. Specifically: latency in figuring out exactly how big a control or layout will be. This also translates into at least 1-frame latency when drawing to a widget based on user input. Imagine a scrubber line on a video timeline or graph, for instance. Non-immediate mode GUI (retained-mode?) means that you can query a layout for exactly how big it will be before it gets drawn. So, if the user clicks at say (100, 200), I know exactly where to draw something in response to that click on top of my widget, without waiting a frame for the GUI to layout. Maybe developers who have come up in the web world don't care, but I find reflow issues to be one of the worst features of browser apps. If you're going for a tight native experience, then this is a huge no-no. The "immediate-mode" GUI idea was something that Casey Muratori, a very influential indie game developer, came up with. Part of his rationale was that it was annoying to store all the state for your widgets in a parallel data structure to the widgets themselves. So why not just draw the widgets, as needed, where you have the local variables and data to draw them? Various developers and frameworks seem to get smitten with this idea, jump on the bandwagon, and then run into the flaws. For a long time the Unity game engine followed this model. I found the GUI easy to get started with, but ultimately limiting. Unity eventually abandoned this approach. Really, this is good for developer-quality in-game debugging UI, but it's not a great approach for creating polished end-user UI. I adopted IMGUI, used it briefly, was impressed by its speed, but ran into massive problems customizing controls to get exactly the right look and feel. My take -- this is an ideologically-driven kind of neat but ultimately dead end. Use it to quickly get a dev GUI going, but it won't see you through to a polished consumer-ready GUI.
- robinei 6y ago
  There is no reason an IMGUI cannot efficiently construct a hierarchy in the background and do a fast Flutter-like linear layout pass on it before processing input and rendering it. Then throw this away and do it all over again for the next frame (or the next time input arrives, if not used in a game-like context). I've experimented with this, and speed is no impediment if implemented correctly. IMGUI is about the immediate mode interface, not about layout/rendering/input handling happening at the same time as view functions are called. And don't do "if (Button()) { ... }", but use lambdas for event handling, so the handlers can be invoked at the proper time when everything is laid out.
varispeed 6y ago
This is neat, but the problem I always had in these type of libraries is that they only work enough for the examples to be usable. As soon as I wanted to do something that was not in examples, that would either won't work at all or needed a horrible hack to work. I can't give a real example from the top of my head, but I am thinking like the examples would not show how to do a modal popup window and then you learn when you try to instatiate such window then the other window goes crazy or if you close the modal window everything closes and there would be no way to fix it other than digging into library code. I hope this one is not like that.
- softawre 6y ago
  Did you read far enough in the readme to see the screenshots of the projects using this already? Those look like very complex UIs, and at least one of them is open source for you to look at.
  - varispeed 6y ago
    It looks very impressive indeed! I may be giving it a go in the near future as I may have an use case for it.
- MattRix 6y ago
  Dear ImGui is not some half-baked experiment. It's used in tons of real world projects right now. The main way I've seen it used is for developer-facing GUI (debug views, tool/editors, etc)
  - deleted 6y ago
    [deleted]
- DonHopkins 6y ago
  I agree. They work fine for simplistic interfaces with a few buttons, but what about more complex widgets, like plain/rich/code text editors, that have a lot of different callbacks and fire many different asynchronous events? Sure, a button function that returns a boolean can be used as a simple parameter to an if statement, but you would would need a switch statement to test for all the different events that a text editor could send. That's a terrible clumsy API! And where do you store the complex state of the attributed text, or parsed source code in a code editor? Do you just pass the entire string in every frame and re-parse html each time? Where do you store and how do you access all the hidden state, like keyboard focus, cursor position, editing modes, etc, that object oriented user interfaces simply expose as properties, getters or setters? And how do you implement an outliner? Do you have to write recursive immediate code that traverses the entire tree every frame? Where do you store the outline opened/closed state, per-item state, and the cursor position? You can't just store that state in the actual objects you're showing in the outline, because that mixes your user interface layer with your data modeling layer. The cure is worse than the disease. You end up cobbling together your own spaghetti-coded special-purpose object oriented retained mode adaptation layer, just what you were trying to avoid by using immediate mode in the first place. And how do you implement efficient scrolling lists or tables or spreadsheets containing thousands or even hundreds of thousands of items? Do you have to pass every single item through the API every frame, instead of implementing callbacks to only pass and cache the items that fit on the screen? And how do you implement graphics editors? Or drag and drop previewing? Or popping up item specific menus and submenus when you right-click on a list or outline item? Or anything more complex than a simple button? Objects and closures and asynchronous event handlers are the best thing that happened to user interface programming since the pixel. Use them!
phkahler 6y ago
>> You will need a backend to integrate Dear ImGui in your app. The backend passes mouse/keyboard/gamepad inputs and variety of settings to Dear ImGui, and is in charge of rendering the resulting vertices Some people say this thing is platform agnostic, which is sort of true. But in no way does it give you a multiplatform GUI. You must provide this "backend" for every OS you want to run on. If you decide to handle that with QT, GTK, or WX, then what use is this?
- tom_ 6y ago
  If you are already using qt, gtk or wx, then dear imgui is not really aimed at you. The intended use case is more the situation where you already have what you term the backend, and you want to add a gui to your program. (There's not much that's platform-specific in dear imgui, so you end up with a GUI that's as multiplatform as your program is.)
- kevingadd 6y ago
  Game devs are probably using SDL2 or equivalent, at which point they can just use SDL2's simple cross-platform primitives to get everything they need to use Dear ImGUI.
  - phkahler 6y ago
    That might be a good idea. I hadn't thought of SDL which would provide a bare minimum to get cross platform.
    - programd 6y ago
      Here is a writeup from someone trying to get SDL to work with Dear ImGui. It kind of works, but... https://retifrav.github.io/blog/2019/05/26/sdl-imgui/ https://retifrav.github.io/blog/2019/05/26/sdl-imgui/ You can feel this persons frustration about all the obscure magic incantations needed to get a simple GUI and some lines on screen. The really awful part is the last bits where he discusses how to get the damn thing compiled on Win/Linux/Mac. Even installing all the needed bits is an ordeal. Only a masochist would love this - which to be fair, probably describes game developers as a group. The real question is why is this so hard? Or rather why does this require so much random obscure knowledge in this day and age? And all of this is so ridiculously brittle. You're one OS upgrade from the whole thing falling apart either on the build side or on the user side. That's why people today just write HTML/JavaScript browser GUI for whatever they're doing and call it a day. It's way easier.
aquova 6y ago
I'm curious on what opinions are on Dear ImGui's bindings in other languages, namely Rust. imgui-rs seems to be one of the only mature-ish GUI libraries, but I found myself struggling with it. The multiple window "debug view" looks great, but for something like an OpenGL window with a simple menu bar, I found it difficult to create. There is also apparently no file picker widget, which I found to be a big downside.
fizixer 6y ago
> Dear ImGui – Bloat-free graphical user interface library for a bloated programming lanugage FTFY
grliga 6y ago
"Dear ImGui is designed to enable fast iterations and to empower programmers to create content creation tools and visualization / debug tools (as opposed to UI for the average end-user)."
anderspitman 6y ago
For those who may be unfamiliar with the "immediate mode" vs "retained mode" terminology here, an aha moment for me was realizing frameworks like React are essentially immediate mode APIs (such as declarative JSX) abstracting an underlying retained-mode system (the DOM). It may not be a perfect analogy, but seems to be basically true.
kevingadd 6y ago
Dear ImGui is amazing software with great ideas, but at this point I feel like the "immediate" is a problematic lie much like how "immediate mode" graphics rendering hasn't been immediate in years. I think the most appropriate way to describe these libraries is "imperative", because you're constructing retained state by running imperative code and the library is responsible for figuring out how to do what you want it to do. Any properly functioning UI with the features needed by more than a handful of users ends up having to retain a considerable amount of state. This doesn't mean that you need to construct a huge graph of interconnected object goo, but a bunch of C/C++ calling functions every frame with no retained state won't cut it. Libraries like Dear ImGui and Nuklear largely solve this with a combination of wasted energy (by running your code repeatedly) and magical hidden state (managing retained state in the background for you automatically). The fact that retained state does end up existing but behind the curtain means that annoying problems manifest themselves due to it being out of your control. For example, a textbox needs to maintain the current selection along with a scroll offset in its viewport, along with an undo/redo history. You might decide to drop some of that but some of it has to stick. In Nuklear's case, it relies on stb_textedit to do a lot of the heavy lifting (great library!) and retains state for you behind the scenes. Because the state management is automatic based on the small amount of information Nuklear has, doing something like collapsing a hideable panel makes the textbox "disappear" at which point the scroll offset, selection and undo/redo history vanish. The user may have accidentally collapsed the panel (or the program did it for them), and you've now responded to that input by throwing away something very important. You certainly could retain all this state inside your application (whether or not there's an API for it in the library is another question), but now you have to come up with a solution for tracking and storing all that state. Other comments have already mentioned the "page tearing" problem (needing an extra frame to respond to state changes, etc) which is one manifestation of this fundamental issue - that retained state is in fact necessary and hiding it creates new problems - but there are other challenges that are easier to ignore. Accessibility is a major one, and current IMGUI libraries are entirely ill-prepared to address it. Another issue is internationalization - not only is RTL text an issue, but complex character sets require shaping (an expensive operation) which also requires caching and additional infrastructure that is going to clash painfully with the very simple "just draw some text" model used by most of these libraries. International text input is also very stateful and you'll find that interacting with IMEs is quite difficult if you aren't careful about things. (This is especially bad because SDL2 itself has a botched IME implementation, so users of non-western character sets are screwed right out of the gate.) I've been using Nuklear over the past couple years for some development tools and the experience soured me on IMGUI libraries in general because I kept running into these problems that, in retrospect, should not have been a surprise. The UI had lots of rough edges you'd feel when using it, it was ugly (until I aggressively patched it to address this), it was slow, etc. Dear ImGui is likely higher quality than Nuklear (not that I can say for sure, because I never got it to work due to integration problems) but the fundamental design principles are largely the same and it has its own set of limitations. I'm hopeful that as time passes these libraries will continue to improve, but I've personally moved on to accepting that a good UI needs retained state and I'm focusing on ways to make constructing that state as easy as possible without leaving users who need accessibility or foreign character sets out in the cold. Some less relevant footnotes: * The performance obsession demonstrated in some of these libraries is an active hindrance and in some cases actually sabotages performance. Text rendering in Nuklear is "simple" but for remotely adequate performance you end up having to build your own layout cache and take other steps to compensate for the fact that text is not "simple" at all. To avoid running out of memory, you need to come up with a GC for your layout cache. Solving various problems like page tearing will require you to run the whole layout/rasterization process for your UI multiple times, so now your fast "immediate mode" code is actually doing all its work repeatedly, burning CPU. So far tearing out Nuklear and replacing it with my own retained mode framework has improved performance and reduced code size. * The degree to which Dear ImGui and Nuklear value convenience is, in my opinion, counter-productive - for example the ability to just drop it in and get a vertex buffer + texture pair with text is great but it turns out to mean that the library is doing a bunch of stuff (like font management) itself and replacing that with something modern is actually... very hard. I think the correct approach here is to take steps to make integration easy instead of going for full 'just clone the repo and run make' convenience. I had to aggressively modify Nuklear to have any hope of integrating proper text support at all (and then I couldn't upstream my changes because it turns out that the "single-header" Nuklear library is not actually single-header. another convenience-oriented lie... we're programmers, we can handle extra header files, can't we?) * Accessibility is really, really hard. More people need it than you'd expect. You need to plan for it in advance, and if you didn't it will be very hard to fix after the fact. I can't say for certain whether Dear ImGui will be able to transition smoothly into an accessible world, but Nuklear's design is woefully unprepared. Every element ideally has a human-readable description (for screen readers) and role (button, etc), and your UI needs to have a coherent structure that can be explored by a screen reader. For users with diminished vision you need robust support for adjustable sizes and theming (so you can improve readability and contrast). You also need to consider alternate input methods - full keyboard, game controller, touch - while these libraries are mostly designed for keyboard+mouse.

284 points by dragonsh 6y ago

ZenPsycho 6y ago

until accessibility is implemented, don’t use this please

minerjoe 6y ago
Is this truly what you want? We're developers, I'd think a call out to help bring in a11y would be better recieved.
- ratww 6y ago
  The problem is that accessibility APIs are very limited and stagnated in every single OS (except maybe Apple). For basic default widgets accessibility works out-of-the-box, but as soon as you want to do something more complex or do custom drawing like Dear ImGui does, you're forced to write WAY more code than anticipated. In Windows, for example, you need significantly more code to get a11y than to draw a custom widget. If you're drawing to a framebuffer like Dear ImGui is doing, it's even worse. In some OSs have to use other APIs (like focus management) to take advantage of the a11y APIs, which is kind of "at odds" with the whole immediate-GUI paradigm. This is amazing new for corporation-backed products like Flutter, React Native or even Qt, because it makes the barriers to entry way higher. On the other hand, open source project will lack the resources to do proper native a11y. Asking OS vendors to have proper accessibility in their OSs is IMO the more appropriate step for accessibility advocates, rather than forcing dozens of Open Source projects to reimplement the same thing over and over.
  - mwcampbell 6y ago
    > Asking OS vendors to have proper accessibility in their OSs is IMO the more appropriate step for accessibility advocates What more should OS vendors do? Is there anything OS vendors could do that would actually help the state of accessibility in fringe GUI toolkits like Dear ImGui? This isn't a rhetorical question. In addition to being an outspoken accessibility advocate on threads like this one, I'm currently a developer on the Windows accessibility team at Microsoft, which owns the UI Automation API among other things, and I want to know what more we should be doing.
    - ocornut 6y ago
      Hello Matt, For a small developer I believe the whole topic seems quite overwhelming. To attract fringe GUI toolkits it would be useful to provide easy-to-chew accessibility samples based over 3d graphics technology (say: take a DirectX11 samples drawing a few text and buttons and make it accessibility compliant).
      - mwcampbell 6y ago
        That's a fair request. All of the full-featured accessibility implementations are buried in complex UI frameworks and browser engines. I'm also aware that the sample UIA provider implementations in the Windows SDK aren't very useful; they all implement a single control in its own HWND, using GDI or GDI+. As part of Microsoft's Hack for Good program, I worked with the developers of the Quorum language and development environment (https://quorumlanguage.com/ https://quorumlanguage.com/) on their UIA implementation. So I know how frustrating it can be for a non-expert to implement UIA, and how easy it is to get it wrong. I'll have to see what I can do about implementing a better sample.
        ratww 6y ago
        Just better documentation, tutorials and samples would improve the situation 100x! The current ones are hard even for veteran native programmers. Next thing I'd love to see would be a simplified API to allow smaller developers to also use it. As it is, only giant companies can afford handling accessibility. A personal wish would be to have an immediate mode imperative API for accessibility that abstracts the Automation Tree. Similar to how Dear ImGui does. Something like: BeginFrame, TextInput, Checkbox, EndFrame, etc... plus some commands to "ask" if the Automation API wants to do something, like moving to the next control. Maybe a Dear ImAccessibility? This would work perfectly for Video Games and would allow accessibility to added even to games that didn't predict it. Games are pretty simple, and don't require too much variety. I worked in an Adventure Game in the past and it would be 100% playable using A11y with something like that. I would love to make a 100% accessible game in the future. This of course could be a simple multi-platform wrapper instead of something from your team.
      - 6y ago
mcdevilkiller 6y ago
Until you understand the objective of the project, don't comment please
- ocornut 6y ago
  I think ZenPsycho is right calling out for accessibility features. It's unfortunate that most low-key UI libraries don't support them, partly because those OS API are so complex and for a non-user it is hard to understand them (much like for English users it is sometimes hard to understand what's needed for localization). A pragmatic way to see it - and arguably it's an issue I don't have answer for - is that the sum of all desirable modern features (incl. but not limited to accessibility features) are growing the scope so complex and large it is also - very unfortunately - hindering innovation. Everyone agrees accessibility features are desirable. Yet if every experimental or hobbyist project needed to implement all accessibility features, those projects wouldn't exist. So two steps forward is costing us one step back here :(. There are _so many things_ dear imgui doesn't do at this point, it can't handle full internationalization and right-to-left text. Maybe it'll catch up. Maybe other solutions will solve this. For now as I don't have the resources to do it all myself. But the more people use and work with a given software the more likely it is to evolve and improve. I would gladly surrender to a much better product than dear imgui that implemented this while also solving the problems dear imgui aims to solve.
  - mcdevilkiller 6y ago
    This is a library for building internal tools, debug GUIs etc. This is not Qt/GTK, or React, or a CSS framework.
    - ocornut 6y ago
      Where do you draw the line? Some companies are using it for polished large tooling which may have thousands of end-users. Those users will eventually want a solution to tackle that.
    - kevingadd 6y ago
      Any internal tool or debug GUI has reasonable odds of becoming a user-facing tool eventually, and it's a matter of time until you end up needing to support staff/customers in territories with RTL languages or ideographic character sets. At that point, you end up regretting most of the corners you cut. I built lots of internal developer tools for a mid-sized western studio and it wasn't long until I had to go back and patch in a bunch of localization support because it turned out the publishers overseas needed to be able to use it and not all of their staff spoke English. Any blind employees were probably completely out of luck (maybe not, I did use Win32.)

Torkel 6y ago

Happy to see ImGui trend here on HN! It is an amazing tool that is used in a lot of game engines for making internal/dev gui:s. The principle of drawing gui "as you go", interleaved with control flow makes it easier+faster to make gui:s. In our company's main app we use ImGui (with customizations) for all gui work (from C++ and Rust).

gambiting 6y ago
I work at one of the largest games publishers out there and I'm pretty sure ImGUI is integrated into all of our games at this point during development for debugging. It's an absolutely fantastic tool. Oh, we do actually sponsor it: https://montreal.ubisoft.com/en/ubisoft-sponsors-user-interface-library-for-c-dear-imgui/ https://montreal.ubisoft.com/en/ubisoft-sponsors-user-interf...
- Torkel 6y ago
  Nice :) Will you use it for user-facing gui:s, looking forward?
  - gambiting 6y ago
    Very unlikely, I don't really see why we would. All of our engines have their own extensive UI tools that can be used to create rudimentary interface very quickly if needed. Maybe if we ever released like a level editor or something, but I'm not aware of any such thing right now.
  - greggman3 6y ago
    As much as I love Dear ImGUI it's arguably not a good UI for user-facing apps (vs dev team apps) Supporting all of unicode, all IMEs, emoji, right-to-left languages, etc. is arguably out of scope for Dear ImGUI.
    - Torkel 6y ago
      Well, maybe. We use it user-facing for suite of niche vr/tele-op applications and it works wonderfully. We have support for Korean, Japanese, Hebrew (serious issues with right-to-left in our implementation though). The thing about ImGui is it puts devs on steroids - adding gui is just sooo fast. And fun. And easy to tweak. And easy to debug. 10X, maybe? I get that for a game maybe the user facing gui is less of an issue - it needs to be really polished and maybe there isn't as "much" gui anyway? But for indie-games and productivity apps, it seems like having a gui option that offers 10X faster development - wouldn't that be really convincing? Even if it isn't 10X, maybe only 1.3X, it still seems like it would be easy to motivate some missing functionality. And I would argue it is way more than 1.3. And looking forward - IME, emoji, right-to-left: those are just PR:s waiting to be written :) I'm incredibly bullish on ImGui paradigm. If programmers gravitate towards it and prefer it as much as they do then there is some real power there. The only bad thing about ImGui is that the Rust port of it... well... sucks. At least the way it handles strings at the moment. Then again I always found Rust's handling of strings to be one of the negatives of that language.

dasloop 6y ago

The widget should keep its state private. ImGui::InputText("string", buf, IM_ARRAYSIZE(buf)); ImGui::SliderFloat("float", &f, 0.0f, 1.0f); And maybe is a C++ lib but the interface is C with namespaces. Odd.

perfunctory 6y ago
The way I understand it, the idea is that widgets don't own the state. They are sort of stateless. Your app owns the state.
- formerly_proven 6y ago
  Exactly, the app owning (most of) the state is precisely the point of ImGui.
Toenex 6y ago
Immediate mode is a stateless design pattern.
Cloudef 6y ago
Public interface with C makes sense. C++ doesn't have portable ABI plus it makes porting harder.

perfunctory 6y ago

I like ideas behind immediate mode gui. It's a bit like React.js only without DOM in between. It's not ideal, it has its own issues, but it could develop further into something more robust, I hope. GUI is hard.

roytries 6y ago

Not sure why this is showing up on HN today. But Dear ImGui is absolutely amazing. And its not just for C++. I use it myself in my C# game engine. (There's a C# port that uses System.Numerics: https://github.com/mellinoe/ImGui.NET https://github.com/mellinoe/ImGui.NET) which I've ported to MonoGame https://github.com/roy-t/ImGui.NET https://github.com/roy-t/ImGui.NET) I've used a lot of different UI frameworks (winforms, WPF, Html/CSS based frameworks, custom game engine frameworks). But for prototyping Dear ImGui and the whole immediate GUI idea is amazing. It even looks quite decent and the new docking support is great :).

flohofwoe 6y ago
The Dear ImGui C++ API also maps very well to C, so well that I actually prefer the C-API when working on a project that's mostly C (instead of using C++ for the UI code and C for everything else as I did before). AFAIK most of the other language bindings are also based on the C-API (which is autogenerated from the C++ API): https://github.com/cimgui/cimgui https://github.com/cimgui/cimgui
mholub 6y ago
We recently started to use Dear ImGUI in our custom game engine. Before we used Unity which has its own immediate mode gui solution. And I have hard time to switch. I don't know if I don't understand how Dear ImGui work yet in comparison to Unity's one but it feels so limited. So main difference is that Unity is multipass (it calls your gui drawing code multiple times per frame) and because of it it supports horizontal layout, vertical layout, custom layout modifiers, styles and it is easy to use in Dear ImGUI I am struggling to write stuff like: layout 3 controls horizontally, allocate fixed size for first and last one and use all left space for middle one or layout next N controls vertically of unknown height and use this background color for them, then layout another set of controls and use different background style for them I am not the person who was actively working on integration it into our engine, so maybe it's the problem of not having documentation on our wrapper...or me not understanding very basics of it
- uryga 6y ago
  honestly, im pretty sure imgui can't help you here, i.e. you have to calculate all the necessary sizes/positions yourself and tell imgui where everything should be

prvc 6y ago

>This library is called Dear ImGui. Please refer to it as Dear ImGui (not ImGui, not IMGUI). >(The library misleadingly started its life in 2014 as "ImGui" due to the fact that I didn't give it a proper name when when I released 1.0, and had no particular expectation that it would take off. However, the term IMGUI (immediate-mode graphical user interface) was coined before and is being used in variety of other situations e.g. Unity uses it own implementation of the IMGUI paradigm. To reduce the ambiguity without affecting existing code bases, I have decided in December 2015 a fully qualified name "Dear ImGui" for this library. Yes, but why "Dear"? Makes it read in an odd way wrt to idiomatic English.

ejolto 6y ago
the owner is french, I bet the french "cher imgui" reads better.
- app4soft 6y ago
  > the owner is french Think, for #dearMoon[0] name "dear" refers to Jules Verne's "Rocket to the Moon".[1] [0] https://twitter.com/dearmoonproject https://twitter.com/dearmoonproject [1] https://en.wikipedia.org/wiki/Jules_Verne%27s_Rocket_to_the_Moon https://en.wikipedia.org/wiki/Jules_Verne%27s_Rocket_to_the_...
- delroth 6y ago
  No, it does not.
amelius 6y ago
> Yes, but why "Dear"? Makes it read in an odd way wrt to idiomatic English. And "ImGui" does not?
reyqn 6y ago
I would guess, since it has been rebranded on christmas day, that it's named Dear ImGui because when you would write a letter to Santa Claus, you would start by "Dear Santa" (or at least in french, "Cher père Noël"). Maybe a parallel is to be made between the library and Santa Claus, because if you ask for something kindly, you would magically have it, without it being cumbersome for you.

database_lost 6y ago

I don't work that much with GUI applications, but Dear ImGui was perfect for a past project and I just wanted to chime in on the positive feedback :) Take care everyone!

srikz 6y ago

Dear ImGui is excellent and is very handy to make GUI version of a CLI app especially if we want to interactively set values and see results. It is fairly low level (deliberately) and that’s great to keep it simple. I wish there is a standalone GUI ‘framework’ which builds on these primitives and leans on standard library to make the experience a bit more nicer when building standalone applications. I understand this is not the goal of Dear ImGui. I may give it a shot in a few months time if I don’t come across any such project.

pansa2 6y ago

Qt seems to be the most popular library for cross-platform GUI apps written in C++. Is Dear ImGui a credible alternative? How does Dear ImGui compare to Qt?

gambiting 6y ago
Well, these are as different as it gets. Dear ImGui is purely code based and it's drawing in immediate mode. Meaning there is no way to have a visual tool to arrange layouts for things, you have to do everything in code. It's fantastic for debugging, prototyping, very simple interfaces when that's all that's required, but it's not a fully fledged UI library like QT. It's like comparing a bicycle to a 4x4. Sure a bicycle works better in some uses cases, but for it's not designed for heavy lifting.
- formerly_proven 6y ago
  ImGui is not drawing in immediate mode (which isn't supported any more in any contemporary accelerated graphics API). Only the API is immediate mode. You can Begin() the same window multiple times and each time you do it during a frame you keep appending to the same window.
  - gambiting 6y ago
    Well yes, sorry, I misspoke.
  - flohofwoe 6y ago
    This point is so important that it bears repeating: only the programming model is "immediate", not the implementation under the hood. Dear ImGui keeps (internal) state around between frames, maybe not as much as other UI frameworks, but it does. Especially the rendering isn't "immediate mode", the UI isn't rendered while running the code that's building the API. Instead Dear ImGui builds a "deferred mode" rendering command list which is actually very efficient in terms of required draw calls. The main difference to traditional UI frameworks is that there are no different code paths for UI creation, UI updating, and handling input. Instead all those things are happening in the same sequential code flow.

modeless 6y ago

One of the most valuable parts of Dear Imgui is the example applications, which are great as a reference and starting point for your own projects. Many different platforms and rendering APIs are covered. Also be sure to check out the 'docking' branch, which implements docking panels and tearaway windows in the style of Visual Studio. There are many low quality versions of this concept in other GUI libraries but I think Dear Imgui's version is the best I've seen outside of Visual Studio itself.

amelius 6y ago

Does it support GPUs and Wayland directly?

flohofwoe 6y ago
ImGui itself doesn't have its own renderer, it just provides a list of simple rendering commands which then must be rendered by your own code (the git repo comes with ready-to-use example renderers using any of the standard 3D-APIs, GL, D3D, Metal, Vulkan, etc...). That way it's easy to integrate into existing code bases and portable to all sorts of "exotic" platforms (for instance game consoles - which generally don't have "standard" APIs).

MaxBarraclough 6y ago

I'm reminded a little of the FOX Toolkit, [0] but ImGui has more of an emphasis on accelerated graphics. [0] http://fox-toolkit.org/ http://fox-toolkit.org/

CyberDildonics 6y ago
How are these similar in any way except for being GUI libraries?
- fao_ 6y ago
  > How are these similar in any way except for being GUI libraries? They didn't say it was similar, they said imgui reminded them of it.

app4soft 6y ago

Is there usable Dear ImGui fork/sample for OpenGL 1.x?

formerly_proven 6y ago
Putting the "immediate" back in "ImGui".
flohofwoe 6y ago
It's definitely possible but I guess nobody has done it yet because the usual GL "baseline" version these days is GLES2 (and that mostly because of WebGL). Each rendering command you get back from Dear ImGui comes with a block of vertices and indices. Typically those are stashed into 3D-API vertex- and index-buffers for efficient rendering, but they can just as well be "unrolled" to glBegin/End calls, it's just not as efficient. With a good GL driver this probably doesn't matter much though.
greggman3 6y ago
All Dear ImGUI does is generate arrays of vertices + texture coordinates. That's it. It doesn't support any particular graphics API. There are examples in the repo but they are just that, examples. If you want to use it in OpenGL 1.0 it shouldn't take you more than a few minutes.
- account42 6y ago
  It definitely does come with backends for various APIs: https://github.com/ocornut/imgui/tree/master/backends https://github.com/ocornut/imgui/tree/master/backends
  - app4soft 6y ago
    > It definitely does come with backends for various APIs: And there are NO imgui_impl_opengl1.cpp & imgui_impl_opengl1.h, only next: ... imgui_impl_opengl2.cpp imgui_impl_opengl2.h imgui_impl_opengl3.cpp imgui_impl_opengl3.h ... UPD: Some say[0] that imgui_impl_opengl2.cpp really is imgui_impl_opengl1.cpp: > imgui_impl_opengl2.cpp is actually misnamed and should be imgui_impl_opengl1.cpp. [0] https://discourse.dearimgui.org/t/missing-glactivetexture-call/409 https://discourse.dearimgui.org/t/missing-glactivetexture-ca...

exDM69 6y ago

As much as I like Dear ImGui, the immediate mode paradigm doesn't work everywhere. The problem of "page tearing" (not to be confused with vsync) means you either need to render frames continuously, or at least 2 frames for every time you get input or need to implement some kind of "retained mode state tracking" on top of Imgui. It's good for games, but for applications where you're not rendering new frames constantly, the paradigm doesn't seem a very good fit. I wish there was a retained mode GUI library that would be as easy to integrate in your game and graphics apps as ImGui (or nuklear) is. On my spare time, I've been working on a retained mode GUI layout and rendering framework (not a complete GUI toolkit) that uses a DOM-like tree, CSS style flexbox layouts and produces a vertex buffer for rendering like ImGui does. Unfortunately life gets in the way, and all I have to show for my project is a small prototype in C and another one in Rust (can't decide which I like more) that draws some text and rectangles with a fancy layout. Code is not public at the moment but I'm willing to share it with anyone (on GitHub) who responds with a thoughtful comment or a good question. I have been following Raph Levien's fantastic work on Druid and Rust GUIs which has been very inspirational, this video in particular [0]. Where Raph is focused on native GUI rendering and high fidelity text output, I've only focused on rendering in a GPU application using shaders and only very basic text layout with simple kerning (like Dear ImGui). As Raph points out in his later talks on the topic, layout and rendering are only half of the GUI puzzle. The other half is maintaining the state of the application, usually through some kind of widget tree. Leave a comment if you're interested, I'd be happy to chat even though it doesn't seem like my projects are going anywhere anytime soon. [0] https://www.youtube.com/watch?v=4YTfxresvS8 https://www.youtube.com/watch?v=4YTfxresvS8 Data Oriented GUI in Rust by Raph Levien

flohofwoe 6y ago
Wouldn't it be possible to separate the public API from the internal implementation so much that the library appears "immediate mode" on the outside, but is completely "retained mode" on the inside? With a persistent widget tree which is only manipulated by diffing it against the current frame's UI description provided by the user code? The important feature of immediate mode UIs is that there's only one sequential piece of code for UI creation, updating and input handling. All I'm saying as the framework user is basically "this is what I want the UI to look like in the current frame". E.g. if the UI that's described in the current frame by user code is completely identical to the last frame's UI, exactly "nothing" would happen, the internal widget tree wouldn't change, and nothing would be rendered.

andybak 6y ago

I haven't properly thought this through but is here a sense in which the React "one way data flow" paradigm is a case of rediscovering immediate mode GUIs on the web?

flohofwoe 6y ago
IMHO there's a lot of overlap between the reactive UI philosophy and the immediate mode UI philosophy. The main difference is IMHO that React is "mainly data" while IMGUI is "mainly code". But code is data and data is code, so... :)
gauchojs 6y ago
I love it until I have to do modals..

hartmel 6y ago

- the developer is the creator of MEKA, a (1998!) Sega Master System emulator, which had the reputation to be the best during a long time (and still may be, I don't know anymore) - WonderBoy Dragon's Trap remake and Street Of Rage 4 for PC/consoles, it's him too I may be wrong, but following the screenshots, the Dragon's Trap development was like : we need tools to write a game ! let's write it ! Wait we need libraries to write tools ! let's write them ! The quality of the game and all the details reflect impressive skills and amount of work.

ahaferburg 6y ago

Every couple months I browse the screenshot threads https://github.com/ocornut/imgui/issues/3488 https://github.com/ocornut/imgui/issues/3488 Looking at them makes me really happy for some reason.

malkia 6y ago
Agreed. These look fantastic, and has been the driving force for folks around here to want to change to that. I just don't know what to expect once we go that route (certainly intrigued, also occurnut is one of the nicest and most responsive people around). We have large 3d level editor, and there has been talks about us trying imgui with it. Slowly moving it out of Qt maybe? There is lot to like now in imgui - especially now that there is proper docking :)

enriquto 6y ago

Widgets are bloat. Is there a similar library but without widgets? Something really, really simple. I just want a canvas to draw, and a handler to receive mouse and keyboard events. No windows, no text, just a framebuffer. Back in the day I was really happy with glut and opengl. You just took the three-line hello world and started drawing stuff without fuss. ImGui seems too unnecessarily complicated for me.

flohofwoe 6y ago
Shameless plug, but check out the Sokol libraries (there's also a header with a Dear ImGui rendering backend sitting on top of sokol_app.h and sokol_gfx.h): https://github.com/floooh/sokol https://github.com/floooh/sokol ...and here's a minimal standalone starter project for writing Dear ImGui apps in C I just created a couple of days ago: https://github.com/floooh/cimgui-sokol-starterkit https://github.com/floooh/cimgui-sokol-starterkit
- enriquto 6y ago
  I love this! I'm currently using my own shit headers, but this stuff is really appropriate. Thanks!
- prime31 6y ago
  ...and here is a slightly more rich starter project that happens to use Sokol + Dear ImGui. It was made to create game tools fast in Zig. https://github.com/prime31/zig-upaya https://github.com/prime31/zig-upaya
pkphilip 6y ago
You can already directly draw using framebuffers etc. However, you will likely end up re-implementing widgets in any case, if your app gets more sophisticated. About UI, it is not necessary that it should be heavy and bloated. Lazarus IDE, for instance, produces very small binaries even for fairly sophisticated UIs and it is quite fast.
- enriquto 6y ago

dgr582systems 6y ago

Dear ImGui is so easy to get working compared to other similar C++ libraries. For small dev teams using C++ that alone makes it super valuable. I hate losing a day to figure out how to link in some crazy, clashing dependencies. Never had that problem with this library.

FullyFunctional 6y ago
Over decades, I had developed an almost not-invented-here attitude exact because dependencies are always such a pita (oh Python hell) and drag in a lot of bloat. Rust is the first language I have used where external dependencies (from crates.io) Just Works(TM). However they can still drag in bloat :)

sime2009 6y ago

Visually it doesn't look so good out of the box. Are there some extra styles or libraries etc out there which implement good looking styles on top of Dear ImGui? Or are dev expected to put their own style on top of it?

skocznymroczny 6y ago
Usually it's used for debug interface in game engines, it's not really meant for full-fledged applications (although you could use it for that usecase).
JabavuAdams 6y ago
It looks good compared to the hand-rolled debug GUIs that game developers often implement themselves on top of OpenGL. But, yeah.

JabavuAdams 6y ago

IMGUI is good on many levels, but also has some serious drawbacks. Specifically: latency in figuring out exactly how big a control or layout will be. This also translates into at least 1-frame latency when drawing to a widget based on user input. Imagine a scrubber line on a video timeline or graph, for instance. Non-immediate mode GUI (retained-mode?) means that you can query a layout for exactly how big it will be before it gets drawn. So, if the user clicks at say (100, 200), I know exactly where to draw something in response to that click on top of my widget, without waiting a frame for the GUI to layout. Maybe developers who have come up in the web world don't care, but I find reflow issues to be one of the worst features of browser apps. If you're going for a tight native experience, then this is a huge no-no. The "immediate-mode" GUI idea was something that Casey Muratori, a very influential indie game developer, came up with. Part of his rationale was that it was annoying to store all the state for your widgets in a parallel data structure to the widgets themselves. So why not just draw the widgets, as needed, where you have the local variables and data to draw them? Various developers and frameworks seem to get smitten with this idea, jump on the bandwagon, and then run into the flaws. For a long time the Unity game engine followed this model. I found the GUI easy to get started with, but ultimately limiting. Unity eventually abandoned this approach. Really, this is good for developer-quality in-game debugging UI, but it's not a great approach for creating polished end-user UI. I adopted IMGUI, used it briefly, was impressed by its speed, but ran into massive problems customizing controls to get exactly the right look and feel. My take -- this is an ideologically-driven kind of neat but ultimately dead end. Use it to quickly get a dev GUI going, but it won't see you through to a polished consumer-ready GUI.

robinei 6y ago
There is no reason an IMGUI cannot efficiently construct a hierarchy in the background and do a fast Flutter-like linear layout pass on it before processing input and rendering it. Then throw this away and do it all over again for the next frame (or the next time input arrives, if not used in a game-like context). I've experimented with this, and speed is no impediment if implemented correctly. IMGUI is about the immediate mode interface, not about layout/rendering/input handling happening at the same time as view functions are called. And don't do "if (Button()) { ... }", but use lambdas for event handling, so the handlers can be invoked at the proper time when everything is laid out.

varispeed 6y ago

This is neat, but the problem I always had in these type of libraries is that they only work enough for the examples to be usable. As soon as I wanted to do something that was not in examples, that would either won't work at all or needed a horrible hack to work. I can't give a real example from the top of my head, but I am thinking like the examples would not show how to do a modal popup window and then you learn when you try to instatiate such window then the other window goes crazy or if you close the modal window everything closes and there would be no way to fix it other than digging into library code. I hope this one is not like that.

softawre 6y ago
Did you read far enough in the readme to see the screenshots of the projects using this already? Those look like very complex UIs, and at least one of them is open source for you to look at.
- varispeed 6y ago
  It looks very impressive indeed! I may be giving it a go in the near future as I may have an use case for it.
MattRix 6y ago
Dear ImGui is not some half-baked experiment. It's used in tons of real world projects right now. The main way I've seen it used is for developer-facing GUI (debug views, tool/editors, etc)
- deleted 6y ago
  [deleted]
DonHopkins 6y ago
I agree. They work fine for simplistic interfaces with a few buttons, but what about more complex widgets, like plain/rich/code text editors, that have a lot of different callbacks and fire many different asynchronous events? Sure, a button function that returns a boolean can be used as a simple parameter to an if statement, but you would would need a switch statement to test for all the different events that a text editor could send. That's a terrible clumsy API! And where do you store the complex state of the attributed text, or parsed source code in a code editor? Do you just pass the entire string in every frame and re-parse html each time? Where do you store and how do you access all the hidden state, like keyboard focus, cursor position, editing modes, etc, that object oriented user interfaces simply expose as properties, getters or setters? And how do you implement an outliner? Do you have to write recursive immediate code that traverses the entire tree every frame? Where do you store the outline opened/closed state, per-item state, and the cursor position? You can't just store that state in the actual objects you're showing in the outline, because that mixes your user interface layer with your data modeling layer. The cure is worse than the disease. You end up cobbling together your own spaghetti-coded special-purpose object oriented retained mode adaptation layer, just what you were trying to avoid by using immediate mode in the first place. And how do you implement efficient scrolling lists or tables or spreadsheets containing thousands or even hundreds of thousands of items? Do you have to pass every single item through the API every frame, instead of implementing callbacks to only pass and cache the items that fit on the screen? And how do you implement graphics editors? Or drag and drop previewing? Or popping up item specific menus and submenus when you right-click on a list or outline item? Or anything more complex than a simple button? Objects and closures and asynchronous event handlers are the best thing that happened to user interface programming since the pixel. Use them!

phkahler 6y ago

>> You will need a backend to integrate Dear ImGui in your app. The backend passes mouse/keyboard/gamepad inputs and variety of settings to Dear ImGui, and is in charge of rendering the resulting vertices Some people say this thing is platform agnostic, which is sort of true. But in no way does it give you a multiplatform GUI. You must provide this "backend" for every OS you want to run on. If you decide to handle that with QT, GTK, or WX, then what use is this?

tom_ 6y ago
If you are already using qt, gtk or wx, then dear imgui is not really aimed at you. The intended use case is more the situation where you already have what you term the backend, and you want to add a gui to your program. (There's not much that's platform-specific in dear imgui, so you end up with a GUI that's as multiplatform as your program is.)
kevingadd 6y ago
Game devs are probably using SDL2 or equivalent, at which point they can just use SDL2's simple cross-platform primitives to get everything they need to use Dear ImGUI.
- phkahler 6y ago
  That might be a good idea. I hadn't thought of SDL which would provide a bare minimum to get cross platform.
  - programd 6y ago
    Here is a writeup from someone trying to get SDL to work with Dear ImGui. It kind of works, but... https://retifrav.github.io/blog/2019/05/26/sdl-imgui/ https://retifrav.github.io/blog/2019/05/26/sdl-imgui/ You can feel this persons frustration about all the obscure magic incantations needed to get a simple GUI and some lines on screen. The really awful part is the last bits where he discusses how to get the damn thing compiled on Win/Linux/Mac. Even installing all the needed bits is an ordeal. Only a masochist would love this - which to be fair, probably describes game developers as a group. The real question is why is this so hard? Or rather why does this require so much random obscure knowledge in this day and age? And all of this is so ridiculously brittle. You're one OS upgrade from the whole thing falling apart either on the build side or on the user side. That's why people today just write HTML/JavaScript browser GUI for whatever they're doing and call it a day. It's way easier.

aquova 6y ago

I'm curious on what opinions are on Dear ImGui's bindings in other languages, namely Rust. imgui-rs seems to be one of the only mature-ish GUI libraries, but I found myself struggling with it. The multiple window "debug view" looks great, but for something like an OpenGL window with a simple menu bar, I found it difficult to create. There is also apparently no file picker widget, which I found to be a big downside.

fizixer 6y ago

> Dear ImGui – Bloat-free graphical user interface library for a bloated programming lanugage FTFY

grliga 6y ago

"Dear ImGui is designed to enable fast iterations and to empower programmers to create content creation tools and visualization / debug tools (as opposed to UI for the average end-user)."

anderspitman 6y ago

For those who may be unfamiliar with the "immediate mode" vs "retained mode" terminology here, an aha moment for me was realizing frameworks like React are essentially immediate mode APIs (such as declarative JSX) abstracting an underlying retained-mode system (the DOM). It may not be a perfect analogy, but seems to be basically true.

kevingadd 6y ago

Dear ImGui is amazing software with great ideas, but at this point I feel like the "immediate" is a problematic lie much like how "immediate mode" graphics rendering hasn't been immediate in years. I think the most appropriate way to describe these libraries is "imperative", because you're constructing retained state by running imperative code and the library is responsible for figuring out how to do what you want it to do. Any properly functioning UI with the features needed by more than a handful of users ends up having to retain a considerable amount of state. This doesn't mean that you need to construct a huge graph of interconnected object goo, but a bunch of C/C++ calling functions every frame with no retained state won't cut it. Libraries like Dear ImGui and Nuklear largely solve this with a combination of wasted energy (by running your code repeatedly) and magical hidden state (managing retained state in the background for you automatically). The fact that retained state does end up existing but behind the curtain means that annoying problems manifest themselves due to it being out of your control. For example, a textbox needs to maintain the current selection along with a scroll offset in its viewport, along with an undo/redo history. You might decide to drop some of that but some of it has to stick. In Nuklear's case, it relies on stb_textedit to do a lot of the heavy lifting (great library!) and retains state for you behind the scenes. Because the state management is automatic based on the small amount of information Nuklear has, doing something like collapsing a hideable panel makes the textbox "disappear" at which point the scroll offset, selection and undo/redo history vanish. The user may have accidentally collapsed the panel (or the program did it for them), and you've now responded to that input by throwing away something very important. You certainly could retain all this state inside your application (whether or not there's an API for it in the library is another question), but now you have to come up with a solution for tracking and storing all that state. Other comments have already mentioned the "page tearing" problem (needing an extra frame to respond to state changes, etc) which is one manifestation of this fundamental issue - that retained state is in fact necessary and hiding it creates new problems - but there are other challenges that are easier to ignore. Accessibility is a major one, and current IMGUI libraries are entirely ill-prepared to address it. Another issue is internationalization - not only is RTL text an issue, but complex character sets require shaping (an expensive operation) which also requires caching and additional infrastructure that is going to clash painfully with the very simple "just draw some text" model used by most of these libraries. International text input is also very stateful and you'll find that interacting with IMEs is quite difficult if you aren't careful about things. (This is especially bad because SDL2 itself has a botched IME implementation, so users of non-western character sets are screwed right out of the gate.) I've been using Nuklear over the past couple years for some development tools and the experience soured me on IMGUI libraries in general because I kept running into these problems that, in retrospect, should not have been a surprise. The UI had lots of rough edges you'd feel when using it, it was ugly (until I aggressively patched it to address this), it was slow, etc. Dear ImGui is likely higher quality than Nuklear (not that I can say for sure, because I never got it to work due to integration problems) but the fundamental design principles are largely the same and it has its own set of limitations. I'm hopeful that as time passes these libraries will continue to improve, but I've personally moved on to accepting that a good UI needs retained state and I'm focusing on ways to make constructing that state as easy as possible without leaving users who need accessibility or foreign character sets out in the cold. Some less relevant footnotes: * The performance obsession demonstrated in some of these libraries is an active hindrance and in some cases actually sabotages performance. Text rendering in Nuklear is "simple" but for remotely adequate performance you end up having to build your own layout cache and take other steps to compensate for the fact that text is not "simple" at all. To avoid running out of memory, you need to come up with a GC for your layout cache. Solving various problems like page tearing will require you to run the whole layout/rasterization process for your UI multiple times, so now your fast "immediate mode" code is actually doing all its work repeatedly, burning CPU. So far tearing out Nuklear and replacing it with my own retained mode framework has improved performance and reduced code size. * The degree to which Dear ImGui and Nuklear value convenience is, in my opinion, counter-productive - for example the ability to just drop it in and get a vertex buffer + texture pair with text is great but it turns out to mean that the library is doing a bunch of stuff (like font management) itself and replacing that with something modern is actually... very hard. I think the correct approach here is to take steps to make integration easy instead of going for full 'just clone the repo and run make' convenience. I had to aggressively modify Nuklear to have any hope of integrating proper text support at all (and then I couldn't upstream my changes because it turns out that the "single-header" Nuklear library is not actually single-header. another convenience-oriented lie... we're programmers, we can handle extra header files, can't we?) * Accessibility is really, really hard. More people need it than you'd expect. You need to plan for it in advance, and if you didn't it will be very hard to fix after the fact. I can't say for certain whether Dear ImGui will be able to transition smoothly into an accessible world, but Nuklear's design is woefully unprepared. Every element ideally has a human-readable description (for screen readers) and role (button, etc), and your UI needs to have a coherent structure that can be explored by a screen reader. For users with diminished vision you need robust support for adjustable sizes and theming (so you can improve readability and contrast). You also need to consider alternate input methods - full keyboard, game controller, touch - while these libraries are mostly designed for keyboard+mouse.