HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
ocornut
imgui
C++2014–2026
ocornut / imgui

imgui

Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies

Games & EmulationMobile & DesktopLibraries & SDKs
Explore on GitHubRead Hacker News discussions
162Distinct people
209Mentions
4Explicit recommenders
77.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies

GitHub

Where it is used

What people are saying

I have done lots of UI interfaces in different platforms. I have used Motif and X Windows, Win32, MFC, Gtk, Qt, Cocoa, simple Web interfaces, DirectX, OpenGL, Metal. I love…

cracrecry used a recommendation phrase. 4 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:01:12 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year209 dated mentions

Observed mentions: 2014-08-11 02:10:27 UTC to 2026-09-03 10:20:38 UTC.

01020302014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 6 mentions; 4 submissions, 2 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 12 mentions; 2 submissions, 10 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 23 mentions; 3 submissions, 20 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 29 mentions; 7 submissions, 22 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 29 mentions; 2 submissions, 27 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 14 mentions; 0 submissions, 14 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 24 mentions; 1 submissions, 23 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 28 mentions; 4 submissions, 24 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 13 mentions; 2 submissions, 11 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 15 mentions; 1 submissions, 14 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC110
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC642
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC716
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC817
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC12210
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC23320
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC29722
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC29227
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC14014
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC24123
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC28424
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC13211
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC15114

What Hacker News says

29 sources
inetknght·Nov 5, 2021
> I loved the fact Qt had it's own standard library, I know some c++ purists won't like that and the qmake , but we need to understand how many platforms Qt targeted and that the col new C++ features were not there on all this platforms when Qt4 was created Indeed so! Qt is living today with the fact that it was built and designed long before C++11 was really a thing (where C++11 is the baseline of modern C++ and I would argue that even C++17 should be considered the baseline). The design decisions of Qt are directly against modern C++ design. I think that's ultimately the core of the problem: that modern Qt is orthogonal, not complementary, to modern C++. Range-for loop? Oops, accidentally detached and deep-copied into a temporary. Move objects? Just, no. unique_ptr? Nah, QScopedPointer. Also still not moveable. make_unique? Nah, reset(n
Read the rest
ew...) and ignore the modern advice that you shouldn't use `new` Qt still takes naked pointers and decides willy-nilly whether to take ownership. It still has examples everywhere for using naked new without even mentioning the context of a smart pointer. It has the concept of "you used new, but the parent actually owns it, unless the parent is null" which is just a time bomb for anyone new to the framework let alone the language. No, there's no way I would recommend Qt to someone who isn't experienced. Since I wouldn't recommend it then it's no wonder to me why Qt isn't used so much. It has little to do with C++ and a lot more to do with the design decisions of Qt itself. > IMO the reason Qt is not used as much is because it uses C++ Arguably. Also arguably is because Qt brings along a lot of unnecessary baggage. You mentioned using Qt requires using qmake (which definitely counts as arcane, if not archaic); cmake does a pretty good job of wrapping qmake but doesn't eliminate it. And all of that is because of Qt's non-standard magical signals & slots system which is really just a more error-prone semi-async system when compared to any other eventing system. Using Qt efficiently strongly needs Qt Creator which isn't nearly as good as Visual Studio or VS Code and not as feature-rich as CLion or other intellij-based IDEs I've used -- but at least it performans way better than CLion or intellij trash. Qt's license changing in 5.15 has also become a significant penalty to non-commercial use. This fact alone means there's no way I'd use Qt in a new project, even a commercial one. Modern Qt developers also have to become javascript developers since Qt's UI is heavily driving towards QML. That's an unfortunate direction and also inhibits adoption of Qt IMO. Why write an application in C++ if you need to learn javascript anyway? There are better feature-rich javascript frameworks with better community adoption and better price points. > what would you use today if you need to make an application for someone, something simple like some buttons, menus and it does a bit of work maybe with some files or the internet), the goal is to be fast and have very few bugs that you will have to support by fixing them For GUI, Dear Imgui [0]. For network, Asio [1]. For files, plain standard streams. They're not fast but if your files are your bottleneck then I'd consider memory-mapped files. [0]: https://github.com/ocornut/imgui [1]: https://www.boost.org/doc/libs/1_77_0/doc/html/boost_asio/re...
In LXQt 1.0.0
dkersten·Sep 7, 2021Recommendation phrase
I love the immediate mode style of developing, but ImGUI specifically, at least without third party patches and extensions, has very awkward and limited layout (for example, I'm still waiting for this to get merged[1], which would make it easier), its styling support is relatively minimal (but it can be made look pretty nice) and its accessibility support is non-existent. I also find the API slightly clunky, although its not bad once you get used to it. Overall, I really like Dear ImGUI and I love how easy it is to expose data to a UI through it. Its much more pleasant to use than a traditional retained mode widgets API. But Dear ImGUI isn't a good general purpose UI (nor was it designed to be one), although I could see the immediate mode API work well for one. I started making a complex editor for a toy engine in it and while it worked o
Read the rest
k, the reasons above made me cut it back to just some basic in-engine stuff and the rest is exposed over an optional embedded web server module and a react app as the editor. Its only a toy, but you would use the in-engine ImGUI editor to see the scene rendered in-engine, move objects around etc, but you would use the react app to edit object properties, add assets and behaviours and whatnot. It made it much easier to create rich editors for things like behavior trees, node graphs, etc. Although since its just a toy, I didn't implement a lot of this stuff yet and haven't had time lately to get back to it. [1] https://github.com/ocornut/imgui/pull/846
In The operating system: should there be one? (2013) [pdf]
AussieWog93·Sep 7, 2021
>Maybe you want to help this person who is trying to integrate harfbuzz: https://github.com/ocornut/imgui/issues/4227 Looks like theirs is far more advanced than mine (mine would just generate a texture per string and cache it, the main problem it solved was being able to display non-ASCII filenames). I don't think there's much I could contribute to them at all. >accessibility APIs expect you to export a tree of objects and push state updates Is this an inherent limitation with the tech itself, or just an arbitrary API limitation?
In The operating system: should there be one? (2013) [pdf]
lavabiopsy·Sep 7, 2021
Maybe you want to help this person who is trying to integrate harfbuzz: https://github.com/ocornut/imgui/issues/4227 The other major thing missing in relation to that is input method support. The problem with those type of APIs and accessibility is that implementing screen reader support basically means making it retained mode in some capacity, because accessibility APIs expect you to export a tree of objects and push state updates.
In The operating system: should there be one? (2013) [pdf]
AussieWog93·Sep 7, 2021Recommendation phrase
>Dear ImGui does not support Arabic (right-to-left, glyph shaping) and will not support Arabic (https://github.com/ocornut/imgui/issues/1343). Vanilla ImGui doesn't, but I both wrapped my head around and then rewrote the text renderer in all of 2 days as a junior dev. This version could support arbitrarily many UTF-8 codepoints with kerning and all and had a negligible performance hit on the machines I tested on. I never upstreamed it (left the company before the product that was using it shipped, actually), but it wouldn't be too hard to reproduce. That's what I love about exposed, lower-level frameworks like Dear ImGui. We didn't aim for accessibility, but I'm sure that would have also been semi-trivial for a dedicated dev who understands what's required.
In The operating system: should there be one? (2013) [pdf]
nyanpasu64·Sep 7, 2021
Dear ImGui does not support Arabic (right-to-left, glyph shaping) and will not support Arabic (https://github.com/ocornut/imgui/issues/1343). I don't think it supports accessibility either. As much as I struggle with Qt's APIs (aging janky Widgets, half-baked QML on the desktop, the item models are an impenetrable byzantine enterprisey API that's simultaneously too open-ended, not flexible enough since it imposes its add/remove/move schema on your model, and too buggy), building a GUI from the ground up is not going to give you internationalization or accessibility, and Qt is.
In The operating system: should there be one? (2013) [pdf]
ggerganov·Aug 31, 2021
> does that actually work in a proper terminal? Yes - all of the examples in the linked repo run in the terminal and are also ported to the Web using Emscripten. > Or is it only when you have a framebuffer available? ImTui creates a framebuffer and renders the scene using ASCII characters into the framebuffer. To create the scene, you can use the entire API of Dear ImGui [0] - it has various options for creating windows, buttons, sliders, tables, checkboxes, colors, etc. You now need to display this framebuffer somehow and also provide input from the keyboard and the mouse. ImTui provides an ncurses interface for this. It uses the ncurses API to render the characters in the terminal and also to grab input from the keyboard and the mouse. Technically, ncurses is an overkill for this application, since ImTui only uses only a very small subs
Read the rest
et of the ncurses functions. But this was the easiest way to make it work. ImTui can be extended with more interfaces. For example, I made a second one which I call "Emscripten" interface. It's purpose is to provide an API to easily export the framebuffer to the JS layer and to easily grab input back from the JS layer. This way, I can have a single application code that builds and runs both in the terminal and on the web. [0] https://github.com/ocornut/imgui
In Writing Programs with Ncurses
lyxell·Jul 13, 2021
> I think what it disregards is the amount of effort that it takes to get to a situation where you have an interactive real-time IDE for the purposes of drawing a tree. I agree with your view, but one of the reasons for this is that there is still a lot to ask from the GUI frameworks in most languages (especially languages like C++ and Rust). However, I still believe that this can change. Raph Levien is driving some pretty targeted work on pushing the state of GUI frameworks for Rust [0]. In C++ Dear ImGui is heavily used by the game development community [1]. My experience is that it is really fast to get a visualization for most projects going in very little time using this framework. See the gallery threads [2] for examples. This project also gets better every month. [0]: https://raphlinus.github.io/rust/druid/2020/09/28/rust-2021....
Read the rest
[1]: https://github.com/ocornut/imgui [2]: https://github.com/ocornut/imgui/issues/3793
In Bret Victor: Learnable Programming (2012)
ktpsns·May 26, 2021
Immediate mode GUIs seem to be some "fresh wind" to desktop GUI toolkits. Apparently they are heavily motivated by gaming and 3D focussed applications. I wonder whether they are also play a role in traditional desktops. The Gio kitchen sink example counts hundred lines of code (https://git.sr.ht/~eliasnaur/gio-example/tree/main/kitchen/k...), but for instance Dear ImGui examples (https://github.com/ocornut/imgui) are suprisingly short and require no headache with layouting containers. I could imagine that coding GUIs from the scratch is "fun again" with such a toolkit. Has anybody carried out a larger traditional (i.e. non 3D focussed) application with an immediate mode GUI toolkit?
In Gio – write immediate-mode GUI programs in Go

Showing the 15 most recent of 29 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.