What does HackerNews think of imgui?
Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies
Dear ImGui is a C++ example: https://github.com/ocornut/imgui
You could also add an optional 'convenience layer' over the lower-level flexible-but-inconvenient core library, as long as the core library can be built and used without the convenience layer.
In essence it's just a way to decouple the actually important library functionality from runtime environment details which might be better implemented outside the C and C++ stdlibs anyway.
It's already as simple as the stdlib IO functions not being asynchrononous while many operating systems provide more modern and performant asynchronous IO APIs. For a specific type of library (such as an image decoder) it's often better to delegate such details to the library user instead of either using the stdlib or having the library talk directly to OS APIs.
PS: this type of library design is actually also quite common in game development, because such libraries must be embeddable in game engine code bases which usually implement their own IO-, threading- and memory-management systems.
What I see there is a spatial interface with complex layout, z-axis and graphical elements. A bit hard to replicate on a normal terminal.
> Does that make ImGui a TUI?
TUI and GUI are not defined by the actual complexity of a real application, but the environment which gives them theoretical abilities. With a GUI, you can have pixel-perfect control over every element. With a TUI, you are normally limited to character-level of control. Of course can you also use pixels without a desktop, but you would still leave the terminal-environment and enter the framebuffer for this or something similar. Though, to be fair, at this point it indeed can become a bit fuzzy.
By the way, I tried to use an immediate mode game UI in the past (Lua-based, SUIT), but somehow I feel more comfortable working with object-based UIs. Perhaps years of object-oriented programming has damaged my brain a bit :)
I think in the past the object-oriented was seen as a big improvement regarding GUI dev, but I guess with regards to game dev, it can be problematic wrt performance.
———
> Immediate Mode GUI... cross platform, very flexible and fast
Link to ImGui: https://github.com/ocornut/imgui
As for alternatives there really is not much to choose from. For small projects which are not reliant on the performance/native designs of Qt, Dear ImGui looks nice[1]. But it is very much tailored for a different Use Case.
Edit: I said that [0] is a nice website. But you only get a complete view of the situation if you cycle through all of the open source licenses. Too bad there is no "Open Source" option. Would hurt their sales I guess...
Is there a macOs equivalent of the Windows Internals [0] books?
I recently came across ImGui [1] which uses C++. I assume that cross platform software from Adobe, Microsoft, etc have C++ at their core and would love to find more in the way of resources for C++ on mac. Anyone?
[0] https://www.amazon.com/Windows-Internals-Part-architecture-m...
> Just copy paste the source code in your source tree
And/Or make a simple CMakeLists.txt like this:
cmake_minimum_required(VERSION 3.22.0)
project(mylib C)
file(GLOB_RECURSE MYLIB_SOURCES
${PROJECT_SOURCE_DIR}/src/*.c
)
file(GLOB_RECURSE MYLIB_HEADERS
${PROJECT_SOURCE_DIR}/include/*.h
)
add_library(${PROJECT_NAME} STATIC ${MYLIB_HEADERS} ${MYLIB_SOURCES})
target_include_directories(${PROJECT_NAME}
PRIVATE "${PROJECT_SOURCE_DIR}/include"
)There are game-like UI libraries (https://github.com/ocornut/imgui) but to use them you have to write your program like you're a gamedev and Conway's Law usually fights that.
If you are interested, checkout my Github template repo [1] - it contains a few examples:
I love Dear Imgui: https://github.com/ocornut/imgui
It is the simplest thing in the world. If you are starting and are going to do 3D graphics anyway you don't need state(you just redraw the screen 60 times per second).
Anything else is extremely sophisticated. I also loved Qt, but the policies got a little cumbersome, and went native.
The big problem is that with state there is a lot of complexity involved that is dependent on a platform, and once you pick one it is hard to change.
The big advantage of 3d graphics and dear imgui or any other open source software is that it works anywhere and you are not as dependent on a single company.
Let me introduce you to https://github.com/ocornut/imgui
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(new...) 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...
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 subset 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.
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....
Has anybody carried out a larger traditional (i.e. non 3D focussed) application with an immediate mode GUI toolkit?
https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b
I would advise to read the code and tinker with Dear Imgui.
He was using Patreon until the end of 2019, but has actually removed it since he already got so much corporate sponsors over the years (His platinum sponsors right now are Blizzard, Google, Nvidia, and Ubisoft... enough said.) And he wholeheartedly deserves all the money, since his UI library is just so monumentally important for anyone doing 3D graphics or gamedev.
I just want to have the external repo as a subfolder in my own repo, updating that subfolder as updates become available.
Casey Muratori first spoke about IMGUI back in 2005, but didn't actually implement it practically: https://www.youtube.com/watch?v=Z1qyvQsjK5Y
In around 2013, Omar Cornut wrote an incredibly high quality practical implementation of Muratori's concept called _Dear ImGui_: https://github.com/ocornut/imgui Using both Cornut's library and Muratori's mindset is incredibly powerful and liberating. Things that would require days of work and multiple files in Qt or Cocoa can be finished in four hours and a couple of hundred lines of IMGUI code. It also uses an order of magnitude less CPU/memory resources (which was an issue for us as we were rendering and displaying RAW video footage in real-time).
I find it amazing that this way of thinking hasn't completely dominated frontend programming by now. There is literally no downside to using the IMGUI concept - entire classes of bugs disappear, and your code is simultaneously smaller, easier to maintain and more logical in flow. It's also a shitload more fun to write (something I think that SWE culture overlooks too much) - you spend the majority of your time writing code that directly renders graphics to the screen, rather than fixing obscure bugs and dealing with the specifics of subclassing syntax.
Immediate-mode UIs are by far the easiest for quick and dirty work. Near trivial to get stuff up on screen you can interact with.
If you think this is obscure, try implementing a slider widget any other way. You need a way to keep track of which slider you were dragging, even when the mouse cursor leaves to another.
From the github page - EDIT: Read the bindings / frameworks page too, https://github.com/ocornut/imgui/wiki/Bindings It's still c++ like.
"""
Officially maintained bindings (in repository):
Renderers: DirectX9, DirectX10, DirectX11, DirectX12, OpenGL (legacy), OpenGL3/ES/ES2 (modern), Vulkan, Metal.
Platforms: GLFW, SDL2, Win32, Glut, OSX.
Frameworks: Emscripten, Allegro5, Marmalade.
Third-party bindings (see Bindings page):
Languages: C, C# and: Beef, ChaiScript, D, Go, Haskell, Haxe/hxcpp, Java, JavaScript, Julia, Kotlin, Lua, Odin, Pascal, PureBasic, Python, Ruby, Rust, Swift...
Frameworks: AGS/Adventure Game Studio, Amethyst, bsf, Cinder, Cocos2d-x, Diligent Engine, Flexium, GML/Game Maker Studio2, Godot, GTK3+OpenGL3, Irrlicht Engine, LÖVE+LUA, Magnum, NanoRT, Nim Game Lib, Ogre, openFrameworks, OSG/OpenSceneGraph, Orx, Photoshop, px_render, Qt/QtDirect3D, SFML, Sokol, Unity, Unreal Engine 4, vtk, Win32 GDI, WxWidgets.
Note that C bindings (cimgui) are auto-generated, you can use its json/lua output to generate bindings for other languages.
"""
""" Ongoing Dear ImGui development is financially supported by users and private sponsors, recently:
Platinum-chocolate sponsors
Blizzard, Google, Nvidia, Ubisoft """
Joke aside, google did a lot of good for imgui's development. I guess they all love side projects.
Here's what Dear ImGui's readme [1] says:
> 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). It favors simplicity and productivity toward this goal, and lacks certain features normally found in more high-level libraries.
> Dear ImGui is particularly suited to integration in games engine (for tooling), real-time 3D applications, fullscreen applications, embedded applications, or any applications on consoles platforms where operating system features are non-standard.
Basically: I wouldn't put Flutter inside a graphics heavy video game. I also wouldn't use ImGui for a social mobile app, or something like a business app that requires accessibility.
In last years a lot projects have appeared, which were trying to compete in GUI toolkit market share. All of them had its scope limited, however they brought quite fresh look on declarative programming interface [0][1], superb 2D rendering pipeline [2][3], ease of embedding [4] and adaption to low-power devices [5] but none of them is "complete".
Personally, I am amazed of the implementation of rxi/lite [6], which is just an app (C with Lua) based on SDL2 library. It uses 2x less RAM than sublime on 1GB file, has lower latency, covers clipboard, keyboard, mouse, drag and drop, some context menus but does it feel native? No. Among many issues, it is easy to report an error with screen-reading software but it is quite common problem in all aforementioned.
Perhaps in future, something like LSP specification will see a daylight, which in outcome will helps us to provide universal, modular, limited to certain scope libraries that can be easily plugged in case of need. Maybe then we will came closer to "native" GUIs. In my experience, there are numerous developers who were trying hard to deliver "complete" GUI toolkit but have failed.
[0]: https://github.com/cycfi/elements
[1]: https://flutter.dev/
[2]: https://github.com/linebender/druid
[3]: https://github.com/servo/pathfinder
[4]: https://github.com/ocornut/imgui
If you need to draw a widget on the screen, there's Dear ImGui [1] that you can use from Go [2]
If you're looking for a desktop toolkit, there's a reason why things like Qt are multidecade endeavours.
It's basically what the JS that gets generated from React JSX is like, and also like immediate mode UI APIs that get used for game tooling a lot: https://github.com/ocornut/imgui
Why almost all links are about years ago? Are not there any new technologies/methodologies for MMOGs that support 90fps, or even more? Something hybrid which supports both server and client sides? And mostly has developed for Unreal Engine or other well-known game engines?
https://github.com/ocornut/imgui https://github.com/cimgui/cimgui
* Revery (language: Reason) - https://www.outrunlabs.com/revery/
* WebView (language: C/C++/Golang) - https://github.com/zserge/webview
* Dear ImGui (bindings exist for many languages!) - https://github.com/ocornut/imgui
* Flutter (language: Dart) - https://flutter.dev/
None have really stood out yet to replace Electron, but the future seems bright.
Also ImGUIs are not multiple pass. That's in implementation detail. Unity's ImGUI is multi-pass. One of the most popular ImGUIs (Dear ImGUI) is single pass
https://pbrfrat.com/post/imgui_in_browser.html
For modal demo check "Popups & modal windows" -> "Modals" example.
This is how it looks in C++ code: https://github.com/ocornut/imgui/blob/master/imgui_demo.cpp#...
[0] https://github.com/ocornut/imgui
Here's the code to draw a slider whose value is stored in a float:
float f = 0.5f;
ImGui::SliderFloat("my float", &f, 0.0f, 1.0f);
The UI is in a separate version of the emulator, launched with the little "UI" button in the top right corner of the image panels (e.g. https://floooh.github.io/tiny8bit/kc85-ui.html?type=kc85_4).
The UI is updated once per 60Hz frame, so you only see a per-frame snapshot of the microchip pins which on its own isn't that useful yet except for a nice blinkenlight effect, but it will make a lot more sense once a step-debugging window is added. This will let you inspect the pins after each CPU instruction (still not as accurate as the emulation, which is running with machine-cycle granularity on Z80, and clock-cycle granularity on 6502 machines.
The emulators are written in C(99), with some platform-specific bits written in Objective-C and Javascript, and in C++ for the UI parts (since Dear ImGui is implemented in C++). Apart from the WebAssembly version, Win32, Linux, OSX and iOS is also supported, but you need to compile those yourself :)
If you’d like to make graphical applications though, I recommend immediate mode frameworks
Start drawing a graph of thousands of numbers with the CPU. Easy enough, but harder than it looks.
Accelerate the graph with the GPU so it has smooth animation, moving, zooming... Easy enough but way harder that it looks.
Take a sound sample, uncompress it and visualize in your graph system. Easy?
Take the sample and filter it with CUDA. Way easier filtering a 1D sample than 2D samples.
Play the filtered sound to "feel it".
Then you can filter 2D images if you want.
I recommend the graphic interface Dear Imgui: https://github.com/ocornut/imgui https://github.com/ocornut/imgui/issues/1902
Way faster development time than any other (states)interface with the disadvantage that it continuously draws in the screen consuming energy. Well worth it for rapid prototyping.
The core feature of React is that your UI is a pure function of your application state. In (e.g.) the Win32 UI, you would receive events, and then need to manually transition your current UI state to the new UI state (hide this button, disable this input, etc).
---
https://github.com/x64dbg/x64dbg
https://github.com/ARMmbed/mbedtls
https://github.com/ch11ng/exwm
https://github.com/DexterLagan/lsh
https://github.com/hellerve/programming-talks#creative-codin...
https://github.com/zulip/zulip/
https://github.com/TechnologyClassroom/SetupNotes/tree/maste...
https://github.com/ocornut/imgui
https://github.com/alseambusher/crontab-ui
https://github.com/fyhertz/libstreaming
https://github.com/OCSInventory-NG/OCSInventory-Server
https://github.com/OCSInventory-NG/UnixAgent
https://github.com/su8/pinky-bar
https://github.com/jakewmeyer/Geo
https://github.com/sevagas/swap_digger
https://github.com/gavinlyonsrepo/bashmultitool
https://github.com/ocornut/imgui
Checkout the screenshot threads https://github.com/ocornut/imgui/issues/1607
Especially desktop apps like this look interesting: https://github.com/ocornut/imgui/issues/1607#issuecomment-37...
And it's small enough to work well with WebAssembly: https://floooh.github.io/sokol-html5/wasm/imgui-emsc.html
What about IMGUI? https://github.com/ocornut/imgui
Secondly, I am worried that there are no mid-level 3D graphic toolkits. We have low-level (very very low-level) like Vulkan, or high-level stuff like Three.js and game engines (which are not what I need, as I write realtime scientific visualization code). What I want is something like imgui (https://github.com/ocornut/imgui), but for 3D. Simple, powerful, and bloat-free. However, I can't find anything like this.
Though I would think it would be similar to something like https://github.com/ocornut/imgui
You are stuck with a massive amount of dependencies (html/css parser, javascript VM...) to various massive projects for what, easy cross platform support? Sure cross platform GUI's have been a problem, but any developer can agree that dependency to this level within professional code is a great way to cause a massive amount of headache from required library changes, bugs and memory leaks that you have NO control over due to it not being your code, required security updates that require code refactoring for no fault of your own, etc.
People keep bringing this up because it is a bad solution to a large problem. Maybe the reason its being rehashed so much is because there is truth to what is being said.
I would try finding a graphics library such as opengl, and build a UI in the spirit of something like:
https://github.com/ocornut/imgui https://github.com/vurtun/nuklear
pcwalton seems to be presuming that part of the contract of an "immediate mode API" is like old-school ones it actually immediately draws to the frame buffer by the end of the call.
Whereas you are talking about modern "immediate mode API"s where the calls just add things to an internal data structure that is all drawn at once, avoiding unnecessary shader switches etc. IIRC this is how Conrod (Rust's imgui library) and https://github.com/ocornut/imgui work, although with varying levels of caching.
One point to make about retained mode GUIs is I remember reading an argument that immediate mode is great for visually simple UIs, such as those in video games, but isn't as good for larger scale graphical applications and custom widgets. For example when rendering a large text box, list or table you don't want to have to recalculate the layout every frame so you need some data structure that sticks around between frames specific to the widget type, so that's what retained mode APIs like Qt do for their widgets.
Sure you can do the calculations yourself for exactly which rows of a table are currently in view and render those and the scrollbar with an immediate mode API, but the promise of toolkits like Qt is that you don't have to write calculations and data structures for every table.
There's also a relatively recent library (C++)