Hacker News Reader

Comment by pansa2 | Hacker News Reader

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?

View on HN

They are very different in terms of usage. Dear ImGui is an immediate mode UI library which means that rendering and evaluation happen at the same time. You write for example:

if (ImGui::Button("X")) { //pressed handler }

This renders the button and handles its state at the same time.

Qt is a more traditional callback based UI although with their own signal/slot system which has nice features like thread safety built in. I last used Qt a while ago though so maybe it works different nowadays.

Qt is a full-fledged application framework with a retained mode GUI being just a part of it. Dear ImGui is a specialized immediate mode GUI library (hence the name).

Depends on what you want to use it for.

Qt is essentially a full-blown operating system wrapper, Dear ImGui is much more focused on creating UIs quickly and has a different background (coming out of the gamedev world for creating inhouse-tools and debugging UIs integrated into games). It's just around 25kloc of code, has no external dependencies, compiles to a few dozen KBytes and is very easy to integrate into an existing code base.

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.

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.

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.

Rather important is the state ImGui keeps around is independent of the number of widgets. (Imgui's inter-frame state is essentially a list of top-level windows, a list of pressed buttons and the ID of the active/focused widget -- that's enough). This makes ImGui perfect for inserting it into the traversal of complex data structures and ensures perfect synchrony between UI and data. This is an area were classic GUI tooling often struggles; sure it's totally possible to do with e.g. Qt but making a scene graph accessible as a Qt model likely amounts to a few thousand lines of code, but is comparatively trivial with tightly-coupled ImGui code. Embedding GUIs into a 3D viewport is also something these frameworks aren't generally designed to do, but is the easiest way to do it with ImGui.

That being said, real GUI frameworks like Qt are a much better choice for 97 % of "end-user tools", because they have all the bells and whistles you do, in fact, want to have in a desktop application (RAD tools, proper layout system, proper menu/action system, accessibility integration, state inspection etc.)

> ... because they have all the bells and whistles...

None of that is incompatible with the immediate-mode-UI philosophy though, it's just that this specific UI toolkit (Dear ImGui) is coming from a direction where those things haven't been that important.

Oh but it is. A proper menu/action system requires the toolkit to retain all menus and actions; ImGui doesn't do that (and shouldn't, considering all the places you can put a menu), it also requires layered event handling, which ImGui doesn't want to have. Accessibility requires a retained widget tree, which ImGui explicitly doesn't want. Layouts are incompatible with the current immediate mode API (but could be implemented in an immediate mode API given a legion of lambdas), because the size of widgets depends on the size and possibly contents of other widgets; for ImGui this is all fixed when you call Button(), which immediately calculates all vertices and adds them to the drawlist (that's the retained part in ImGui). There are probably many more points.

I still see those mostly as implementation details of this specific library (Dear ImGui), not as problems of the general idea of UIs that are described through an immediate mode API. I'm sure I'm missing a few important details, but what's preventing another library to make the internals more retained while keeping the illusion of an immediate mode UI on the user side of the API (which is the important part).

The internal implementation may be much more complicated than what Dear ImGui does, maybe it's necessary to run multiple passes over the UI description to create the layout, etc... but that might be worth it if the programming model remains as simple as it is now.

Well yes, sorry, I misspoke.

I'm not disagreeing with you that Dear ImGUI is not at the same level as Qt for an end-user app but if you want to make a visual tool for creating UIs in ImGUI there is nothing stopping you. You write some tool to walk over your description of the data and call the correct functions. Nothing hard or special about it.

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.

Reply on news.ycombinator.com