For tools like this, programmers are also just "normal users", and from the developer side, I'm sure they evaluated various alternatives with all their pros and cons before settling for Dear ImGui.
So yes, the experience was not good, and I don't see what these tools would lose by using a proper GUI. I don't want every utility to drain my laptop battery like a decent video game.
ImGui is great if you already have a loop where everything is unconditionally redrawn every frame, but otherwise it's a really odd choice for an end-user application.
It seems like an issue of how it is implemented. I think Tracy does it well. It's party my fault since Dear ImGui lib and backends currently doesn't have an "official" way to tackle this, so everyone does their own sauce and it's easy to make a mistake. But I have zero doubt it is doable.
> I don't see what these tools would lose by using a proper GUI.
What they would lose is that they wouldn't exist in the first place or wouldn't be as full-featured. I'm surprised this is so hard to comprehend? In spite of its shortcomings, software like Dear ImGui is an enabler to make things exists and happen.
These are some pretty bold statements.
* "They wouldn't exist in the first place" implies that ImGui was the primary reason and foundation for creating these programs. As if using the traditional retained mode GUI is so unbearable that without ImGui the authors would have abandoned the idea of creating these tools in the first place.
* "Or wouldn't be as full-featured" implies that ImGui is either more full-featured or (if you meant time) is faster to develop with compared to a traditional retained mode GUI.
> I'm surprised this is so hard to comprehend?
Well, I'm surprised that some people keep presenting the immediate mode GUI as the silver-bullet alternative to the traditional GUI. Don't get me wrong: I understand that IMGUI is a great tool if you need to quickly add a throway GUI to a game, but otherwise there is a price to pay, both by the developer and the end user.
I'm saying it is making some development - those that are well aligned with the frameworks qualities - particularly efficient. Efficiency and productivity are everything. Productivity is often a major contributor in bridging the gap between cancelled and released, between painful and pleasant, between under-featured and full-featured, between abandoned and maintained, between unprofitable and profitable.
So while not saying things are simple to describe and compare, they are not, Dear ImGui focus on high-productivity is the reason why it has been adopted by some people.
> without ImGui the authors would have abandoned the idea of creating these tools in the first place.
It is probable those particular authors would have, yes.
I meant, it's not a secret that many engineers are totally afraid or uninterested in UI programmers. A common feedback is of certain people saying "hey, dear imgui made UI programming fun for me". So I'm confidently saying that SOME software wouldn't have existed without dear imgui. It being so brutally different in term of philosophy, coding style, culture, by definition makes it reach a different crowd.
> implies that ImGui is either more full-featured or (if you meant time) is faster to develop with compared to a traditional retained mode GUI.
Dear ImGui is clearly LESS full-featured than e.g Qt, but for some uses is is faster to develop with than most other frameworks.
> creating user interfaces for mobile and the desktop, avoiding the platform bound and often complex native toolkits
Especially for mobile, just use the native toolkit, or something that uses the native toolkit for its backend. I'm sick of using apps that don't use the native toolkit, they almost always have worse performance and just behave in weird ways. Even flutter is guilty of this, and that has all the manpower of a google team behind it.
A mobile app using immediate mode, written in _Go_, just sounds like a recipe for an app that will never function as well as its equivalent written specifically for the platform.
Stop sacrificing the experience of your users for your own personal developer experience.