It also looks specifically for .exe files, when a linux compiler won't append that suffix.
It also looks in the x64 directory, which was not created when I ran it.
For some reason even though I have dotnet 8.x installed it compiled with dotnet 6.x and complained about 6.x being obsolete.
The generate_project script also looks for a .exe file, but even when stripped off the process fails with namespace errors for 'main' and 'sharpmake'. These errors occur in a temporary file unfortunately so they're hard to investigate.
I've thoroughly enjoyed using ImGui for tooling around image processing, computational geometry, a bunch of 3D projection stuff. The fact that it's based on OpenGL or Vulkan or whatever backend you want is a big win for this kind of work. I can just take a bunch of pixels, throw them into a texture, and render some quads with those textures painted on them after going through some 2D transformations or 3D projection/transformation. It's quite beautiful for all of this. ImPlot for doing basic data plotting and the built-in ImGui widgets for controlling the whole thing.
I have otherwise mostly given up on making GUI applications because I simply don't have time to pick up a bunch of UI toolkits for all the different platforms, pulling a massive dependency into my project and requiring constant maintenance to keep the program working.
It can be a bit wonky though, I regularly spot UI/UX decisions that seem to map more closely to what the developer is doing under the hood, or their own mental model of the problem, than what one might consider to be an intuitive way of interacting with the system.
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.
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.
On one hand I agree. On the other: where are these high performance real-time GUI kits these days? If it came down to IMGUI or shoving Electron into my app...
It is popular mostly because all alternatives are really bad, if "all" you want is a functional GUI to deliver some developer tool. Qt means you have to dive really deep into a C++ project. The web technologies are all far too heavy and complex and you don't really any of the power. There also are many other alternatives, none of them really do what ImGui does.
Installation
Add two files to your project:
src/im_anim.h
src/im_anim.cpp
That's it. No build system changes, no external dependencies.Enjoy/
https://claude.ai/share/12357895-d585-4475-93fb-cdb5eba5dd76
tl;dr It's not an implicit animation framework like Core Animation or CSS animations. Instead, each frame you get the current value which is then used, and the actual tween curve only changes when you call a tween function with a new target; otherwise, you get the current (tweened) value since the last time the target changed (which might be the final value).
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.
Update: I figured out that you need to run a git submodule update command first. The shell script is supposed to tell you this but it is broken. This does a bunch of work but then dies because g++ doesn't stick the string ".exe" on the end of executibles. Also, the script looks in the wrong place for the output. A few text fixes in the bootstrap.sh and generate_projects.sh files and it gets to a point where the build is dying due to not having "main" or "sharpmake" objects in the current context, whatever that means. I don't know enough about C# to go further, especially for what was supposed to be a quickie 10 minute test. I'm hoping someone else figures this out and updates the repo.