extensible-effects VS imgui

Why do you need a GUI library, if you can write your application using extensible effects frameworks, just choose any and enjoy!

I would say that the distinction between TUI and GUI - outside "how would I use this tool remotely" - is mainly one for the developer. Take ImGui (https://github.com/ocornut/imgui, an immediate mode GUI library) for example - the examples are much closer to TUI interfaces than a Swift UI app - the only difference between that an a terminal UI would be that the lines are thinner and that text has non-uniform spacing.

Does that make ImGui a TUI? Or make TUIs a GUI? Why are those thin visual lines graphical, if the slightly thicker visual lines drawn by your graphical terminal emulator with support arbitrary color precision and inline image rendition is not?

Maybe the issue is that it there is a terminal emulator to visualize the representation. But if an application that is not graphically heavy and needs an intermediary is a TUI, does that make most utility electron apps TUIs?

The difference between a TUI and a GUI is just an implementation detail, and these do not matter in the distinction of desktop app or not. Heck, some modern terminal UIs are more graphically appealing than some GUI apps.

> The established definition of desktop, mobile, gui, tui and commandline is pretty consistent for some decades now I would say.

Considering that all good desktop apps were TUI apps 3 decades ago, that mobile apps are in their modern form has basically only existed for 1.5 decades, and that running mobile apps as desktop apps and the general merge between the disciplines is only a few years old at most, I'd say that this statement doesn't quite hold.

> Take ImGui (https://github.com/ocornut/imgui, an immediate mode GUI library) for example - the examples are much closer to TUI interfaces than a Swift UI app - the only difference between that an a terminal UI would be that the lines are thinner and that text has non-uniform spacing.

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.

One thing I'd do, is at minimum is set up a base project that meets your minimum requirements, say presenting to the screen, drawing and compute shaders. Once that's done, follow through ImGUI for a good graphics based window framework and do something neat with that.

Need more context. Post your main loop: in https://github.com/ocornut/imgui/blob/master/examples/example_win32_directx12/main.cpp

https://github.com/ocornut/imgui/issues/5886

(And keep in mind that many of those are week-end / hobby projects, by people who prefer to focus on other things than the GUI of their projects.)

The people who actually make immediate mode GUIs disagree with you. https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi...

If you want a strict C++ equivalent to SDL the clear answer is SFML. If you just want to visualize 2D/3D data there's matplot++. If you want something slightly higher-level than SDL/SFML (with pre-made UI widgets and such) there's imGUI. If you need an all-in-one GUI solution for desktop or mobile apps there's Qt.

When you create a window in ImGui, it allocates memory but never releases it, so make sure that you are not creating windows with a different name at each frame. This issue may be related: https://github.com/ocornut/imgui/issues/2636

True, some modules are under the GPL only. Here[0] is a very nice website showing an overview.

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.

[0] https://www.qt.io/product/features

[1] https://github.com/ocornut/imgui

I basically took the official ImGUI Vulkan backend and translated it to its equivalent in my engine.