Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear ImGui – Bloat-free graphical user interface library for C++

github.com

Post reply on HN
Print view View original

51–60 of 186 posts

Re: Dear ImGui – Bloat-free graphical user interface library for C++

#51

Post by mholub »

roytries wrote: post #7

Not sure why this is showing up on HN today. But Dear ImGui is absolutely amazing. And its not just for C++. I use it myself in my C# game engine. (There's a C# port that uses System.Numerics: https://github.com/mellinoe/ImGui.NET ) which I've ported to MonoGame https://github.com/roy-t/ImGui.NET ) I've used a lot of different UI frameworks (winforms, WPF, Html/CSS based frameworks, custom game engine frameworks). Bu…

We recently started to use Dear ImGUI in our custom game engine. Before we used Unity which has its own immediate mode gui solution. And I have hard time to switch. I don't know if I don't understand how Dear ImGui work yet in comparison to Unity's one but it feels so limited.

So main difference is that Unity is multipass (it calls your gui drawing code multiple times per frame) and because of it it supports horizontal layout, vertical layout, custom layout modifiers, styles and it is easy to use

in Dear ImGUI I am struggling to write stuff like:

layout 3 controls horizontally, allocate fixed size for first and last one and use all left space for middle one

or

layout next N controls vertically of unknown height and use this background color for them, then layout another set of controls and use different background style for them

I am not the person who was actively working on integration it into our engine, so maybe it's the problem of not having documentation on our wrapper...or me not understanding very basics of it

Re: Dear ImGui – Bloat-free graphical user interface library for C++

#54

Post by HelloNurse »

flohofwoe wrote: post #44
exDM69 wrote: post #39

As much as I like Dear ImGui, the immediate mode paradigm doesn't work everywhere. The problem of "page tearing" (not to be confused with vsync) means you either need to render frames continuously, or at least 2 frames for every time you get input or need to implement some kind of "retained mode state tracking" on top of Imgui. It's good for games, but for applications where you're not rendering new frames constantly…

Wouldn't it be possible to separate the public API from the internal implementation so much that the library appears "immediate mode" on the outside, but is completely "retained mode" on the inside? With a persistent widget tree which is only manipulated by diffing it against the current frame's UI description provided by the user code? The important feature of immediate mode UIs is that there's only one sequential p…

Avoiding the burden of a "widget tree" that duplicates application state in complicated, inefficient and error-prone ways is more or less the whole point of reconstructing the whole GUI every frame from data structures that deserve to exist.

Re: Dear ImGui – Bloat-free graphical user interface library for C++

#55

Post by formerly_proven »

flohofwoe wrote: post #49
formerly_proven wrote: post #41

Earlier quoted context omitted.

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 to…

> ... 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.

Re: Dear ImGui – Bloat-free graphical user interface library for C++

#56

Post by uryga »

mholub wrote: post #51
roytries wrote: post #7

Not sure why this is showing up on HN today. But Dear ImGui is absolutely amazing. And its not just for C++. I use it myself in my C# game engine. (There's a C# port that uses System.Numerics: https://github.com/mellinoe/ImGui.NET ) which I've ported to MonoGame https://github.com/roy-t/ImGui.NET ) I've used a lot of different UI frameworks (winforms, WPF, Html/CSS based frameworks, custom game engine frameworks). Bu…

We recently started to use Dear ImGUI in our custom game engine. Before we used Unity which has its own immediate mode gui solution. And I have hard time to switch. I don't know if I don't understand how Dear ImGui work yet in comparison to Unity's one but it feels so limited. So main difference is that Unity is multipass (it calls your gui drawing code multiple times per frame) and because of it it supports horizont…

honestly, im pretty sure imgui can't help you here, i.e. you have to calculate all the necessary sizes/positions yourself and tell imgui where everything should be

Re: Dear ImGui – Bloat-free graphical user interface library for C++

#57

Post by masterofmisc »

roytries wrote: post #7

Not sure why this is showing up on HN today. But Dear ImGui is absolutely amazing. And its not just for C++. I use it myself in my C# game engine. (There's a C# port that uses System.Numerics: https://github.com/mellinoe/ImGui.NET ) which I've ported to MonoGame https://github.com/roy-t/ImGui.NET ) I've used a lot of different UI frameworks (winforms, WPF, Html/CSS based frameworks, custom game engine frameworks). Bu…

Cool. Does that mean I can use this in a C# Console app?

Re: Dear ImGui – Bloat-free graphical user interface library for C++

#58

Post by milansuk »

exDM69 wrote: post #39

As much as I like Dear ImGui, the immediate mode paradigm doesn't work everywhere. The problem of "page tearing" (not to be confused with vsync) means you either need to render frames continuously, or at least 2 frames for every time you get input or need to implement some kind of "retained mode state tracking" on top of Imgui. It's good for games, but for applications where you're not rendering new frames constantly…

Hi, I'm making SkyAlt[0]. It's IDE and language for building applications. Probably I did something right in the beginning, because It doesn't have problems with "page tearing", but it's true that It does "state tracking" in the background.

Feel free to check my blog and send me an email if you are interested. I have work in progress version for Windows and Linux, but no documentation yet. It will be released(free and open-source) by end of this year.

[0] https://skyalt.com/

Re: Dear ImGui – Bloat-free graphical user interface library for C++

#59

Post by ocornut »

mcdevilkiller wrote: post #37
ZenPsycho wrote: post #2

until accessibility is implemented, don’t use this please

Until you understand the objective of the project, don't comment please

I think ZenPsycho is right calling out for accessibility features. It's unfortunate that most low-key UI libraries don't support them, partly because those OS API are so complex and for a non-user it is hard to understand them (much like for English users it is sometimes hard to understand what's needed for localization).

A pragmatic way to see it - and arguably it's an issue I don't have answer for - is that the sum of all desirable modern features (incl. but not limited to accessibility features) are growing the scope so complex and large it is also - very unfortunately - hindering innovation. Everyone agrees accessibility features are desirable. Yet if every experimental or hobbyist project needed to implement all accessibility features, those projects wouldn't exist. So two steps forward is costing us one step back here :(. There are _so many things_ dear imgui doesn't do at this point, it can't handle full internationalization and right-to-left text. Maybe it'll catch up. Maybe other solutions will solve this. For now as I don't have the resources to do it all myself. But the more people use and work with a given software the more likely it is to evolve and improve. I would gladly surrender to a much better product than dear imgui that implemented this while also solving the problems dear imgui aims to solve.

Re: Dear ImGui – Bloat-free graphical user interface library for C++

#60

Post by flohofwoe »

HelloNurse wrote: post #54
flohofwoe wrote: post #44

Earlier quoted context omitted.

Wouldn't it be possible to separate the public API from the internal implementation so much that the library appears "immediate mode" on the outside, but is completely "retained mode" on the inside? With a persistent widget tree which is only manipulated by diffing it against the current frame's UI description provided by the user code? The important feature of immediate mode UIs is that there's only one sequential p…

Avoiding the burden of a "widget tree" that duplicates application state in complicated, inefficient and error-prone ways is more or less the whole point of reconstructing the whole GUI every frame from data structures that deserve to exist.

Agreed, but in traditional UI toolkits this burden is on the user-side. If the widget tree is hidden away inside the library it becomes just an internal implementation detail, a caching structure which might help make some things more efficient. Proof is in the pudding of course.
Post reply on HN