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?
Dear ImGui – Bloat-free graphical user interface library for C++
81–90 of 186 posts
Re: Dear ImGui – Bloat-free graphical user interface library for C++
#82IMGUI 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.
Re: Dear ImGui – Bloat-free graphical user interface library for C++
#83Visually 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?
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).
Re: Dear ImGui – Bloat-free graphical user interface library for C++
#84Visually 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?
It looks good compared to the hand-rolled debug GUIs that game developers often implement themselves on top of OpenGL. But, yeah.
Re: Dear ImGui – Bloat-free graphical user interface library for C++
#85Earlier quoted context omitted.
Is this truly what you want? We're developers, I'd think a call out to help bring in a11y would be better recieved.
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 widg…
> 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.
Re: Dear ImGui – Bloat-free graphical user interface library for C++
#86Widgets 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.
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.
Re: Dear ImGui – Bloat-free graphical user interface library for C++
#87Qt 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?
No. It's super easy to get going with IMGUI which is what so many solo developers love. I want to make my thing, not learn a new framework. The problem is it won't take you all the way to a polished user-facing GUI without you having to re-write a bunch of it.
Re: Dear ImGui – Bloat-free graphical user interface library for C++
#88IMGUI 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…
I don’t exactly understand argument about frame rates, I thought these GUIs ran at very high frame rates and 1 frame wouldn’t be perceptible by humans. Is there really a human perceptible significant latency with them?
Re: Dear ImGui – Bloat-free graphical user interface library for C++
#89IMGUI 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…
I don’t exactly understand argument about frame rates, I thought these GUIs ran at very high frame rates and 1 frame wouldn’t be perceptible by humans. Is there really a human perceptible significant latency with them?
There are a lot of hidden traps when rendering anything on modern operating systems that add small latencies and those small latencies add up quickly (it was much easier on old 8- and 16-bit computers).
For instance rendering something that "sticks" to the system mouse pointer and doesn't lag a few pixels behind when moving the mouse is surprisingly hard if you're rendering through a 3D API (compared to going through the native window system), at least if you also want to be energy efficient (e.g. not spam 1000 frames per second).
What strikes me as odd is describing the ImGui idea as an "ideology" when it's the most pragmatic way to describe user interfaces in a long time, for me that's the opposite of an ideology.
Re: Dear ImGui – Bloat-free graphical user interface library for C++
#90Earlier quoted context omitted.
I don’t exactly understand argument about frame rates, I thought these GUIs ran at very high frame rates and 1 frame wouldn’t be perceptible by humans. Is there really a human perceptible significant latency with them?
There are a lot of hidden traps when rendering anything on modern operating systems that add small latencies and those small latencies add up quickly (it was much easier on old 8- and 16-bit computers). For instance rendering something that "sticks" to the system mouse pointer and doesn't lag a few pixels behind when moving the mouse is surprisingly hard if you're rendering through a 3D API (compared to going through…
I think if it as Casey Muratori's "brain fart" that made sense in his context but that other developers have latched on to because of his influence in indie game circles.
I have massive respect for him, and followed everything he did back in the late '90s and early aughts, but he's quite opinionated and has some peculiar code aesthetics / trade-offs.