I was interested and wanted to see how much the animations burn CPU and whatnot, so I cloned the repo and went to try to build the demo but everything went to hell. The build environment is some .net thing written in C#. It comes with a "bootstrap.sh" file to get it going that immediately fails, even after installing the dotnet development environment. I fiddled around with it for some time before giving up because I was hitting an error about a Targeting Pack that was going to require me to hit a Microsoft website to fix.
But the README says the build process it just a couple of files so I figured I could just build it by hand. This involved downloading a couple more repos from the author's repo and setting up some symlinks, includes, and defines that I figured out through trial and error, but in the end I was not successful in getting the demo to build. I tried a combo of SDL2 and OpenGL3 but it bombed out with a C++ error about too many initalizers. The only good news is that I was able to cleanly build the demo_im_app code, but the main requires the ImPlatform which appears to be buggy.
ImGui is great if you need an ad-hoc UI for development/debug tools, but it's not meant to be used in actual applications aimed at end-users. I can't speak for other devs but I certainly wouldn't want my development tools waste time with pointless animations. I hope this doesn't encourage even more devs to build inaccessible software featuring ImGui's idiosyncratic, non-standard UX.
I agree with your points about ImGui's intended use case, though I think the landscape is a bit more nuanced. You're right that ImGui excels for dev tools and that its non-standard UX isn't ideal for end-user apps. That said, devs reach for ImGui in end-user apps because lightweight cross-platform alternatives are scarce. Qt is heavy, Electron is heavier, native toolkits mean multiple codebases.
I built a techy tool with ImGui (JSONL Viewer Pro) and it works well enough for users who care more about functionality than polish. Not saying it's right for consumer apps, but for technical tools it can be pragmatic.
It also have bindings for a ton of languages, so for people who jump languages a lot, it's always nice to be able to reach for something more familiar that you can learn across different codebases but same concepts. Same thing for the backend/engine, UI code remains the same, but easy to switch to others or even wrapping it yourself for platforms that are under NDA.
For applications where the aim is high sales volume and low support, you're absolutely right.
But "development/debug tools" is actually just a subset of professional or industrial utility applications where user count is low and support is on the extremes (either "capable self-support" or "Yes, Bob, of course we'll add that for you").
And in those utility applications, you probably don't need the noisy toy animations associated with modern consumer software, but animated data representations can be really valuable.
IME, it's great for building full standalone applications. I've used it to build several internal tools for non-engineers. A tool like that doesn't need to work with a screen reader, or have native buttons, etc. It needs to be easy to build and iterate on.
This isn't to say a tool for non-engineers should have animations to make it useful. ImAnim should probably be used sparingly, if at all.
If you need the features of a full GUI toolkit, then by all means use Qt or wxWidgets etc, but that's a very big jump in project complexity.
imgui success is a silent protest from tons of C++ developers, fed up with the over-engineering and enterprise-ification of everything in this bloated ecosystem.
If the author is around, can you do a short writeup on how this implemented? I've got my own immediate-mode UI framework and am curious how you did it.
The author here.
You have various concepts but overall we store the start time and that's it :D the rest are details, clip, tween, easing function, anchor have surviving resizing, stagger to generate the same anim with variations. Or variations of clips, loop.
Proper anim of colors in oklab, oklch, linear srgb, hsl, ...
Anyway I cannot explain much it's really simple code with a userfriendly front-end.
I was interested and wanted to see how much the animations burn CPU and whatnot, so I cloned the repo and went to try to build the demo but everything went to hell. The build environment is some .net thing written in C#. It comes with a "bootstrap.sh" file to get it going that immediately fails, even after installing the dotnet development environment. I fiddled around with it for some time before giving up because I was hitting an error about a Targeting Pack that was going to require me to hit a Microsoft website to fix.
But the README says the build process it just a couple of files so I figured I could just build it by hand. This involved downloading a couple more repos from the author's repo and setting up some symlinks, includes, and defines that I figured out through trial and error, but in the end I was not successful in getting the demo to build. I tried a combo of SDL2 and OpenGL3 but it bombed out with a C++ error about too many initalizers. The only good news is that I was able to cleanly build the demo_im_app code, but the main requires the ImPlatform which appears to be buggy.
[dead]
[dead]
Bliss:
[dead]
ImGui is great if you need an ad-hoc UI for development/debug tools, but it's not meant to be used in actual applications aimed at end-users. I can't speak for other devs but I certainly wouldn't want my development tools waste time with pointless animations. I hope this doesn't encourage even more devs to build inaccessible software featuring ImGui's idiosyncratic, non-standard UX.
I agree with your points about ImGui's intended use case, though I think the landscape is a bit more nuanced. You're right that ImGui excels for dev tools and that its non-standard UX isn't ideal for end-user apps. That said, devs reach for ImGui in end-user apps because lightweight cross-platform alternatives are scarce. Qt is heavy, Electron is heavier, native toolkits mean multiple codebases. I built a techy tool with ImGui (JSONL Viewer Pro) and it works well enough for users who care more about functionality than polish. Not saying it's right for consumer apps, but for technical tools it can be pragmatic.
It also have bindings for a ton of languages, so for people who jump languages a lot, it's always nice to be able to reach for something more familiar that you can learn across different codebases but same concepts. Same thing for the backend/engine, UI code remains the same, but easy to switch to others or even wrapping it yourself for platforms that are under NDA.
For applications where the aim is high sales volume and low support, you're absolutely right.
But "development/debug tools" is actually just a subset of professional or industrial utility applications where user count is low and support is on the extremes (either "capable self-support" or "Yes, Bob, of course we'll add that for you").
And in those utility applications, you probably don't need the noisy toy animations associated with modern consumer software, but animated data representations can be really valuable.
IME, it's great for building full standalone applications. I've used it to build several internal tools for non-engineers. A tool like that doesn't need to work with a screen reader, or have native buttons, etc. It needs to be easy to build and iterate on.
This isn't to say a tool for non-engineers should have animations to make it useful. ImAnim should probably be used sparingly, if at all.
If you need the features of a full GUI toolkit, then by all means use Qt or wxWidgets etc, but that's a very big jump in project complexity.
imgui success is a silent protest from tons of C++ developers, fed up with the over-engineering and enterprise-ification of everything in this bloated ecosystem.
[dead]
oh wow this timing is incredible for me thank you, this is exactly the type of thing I needed and this is EXACTLY my aesthetic
If the author is around, can you do a short writeup on how this implemented? I've got my own immediate-mode UI framework and am curious how you did it.
The author here. You have various concepts but overall we store the start time and that's it :D the rest are details, clip, tween, easing function, anchor have surviving resizing, stagger to generate the same anim with variations. Or variations of clips, loop. Proper anim of colors in oklab, oklch, linear srgb, hsl, ... Anyway I cannot explain much it's really simple code with a userfriendly front-end.
Not the author but it‘s implemented in only two files which can be studied on Github.