ocornut
I generally love the STB libraries but I have to agree that stb_textedit is/was a false economy at least for my use case of Dear ImGui. I can't fault the design but if you want a fancy text editor the value you get from stb_textedit is rather minor compared to whole things, and it gets in the way. I will aim to remove it from dear imgui at some point.
The mere fact that a software maintainer would merge code without knowing what it does says more about the terrible state of software.
The sum of all those parts IS the actual meat of the engine imho.
People mistakenly assume that rendering something and having a Dear ImGui frontend constitute an engine but it's only the tip of iceberg. Actual real world issues, productivity concerns, getting shit done is the meaningful work.
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.
Effectively people are hasty and don't spend the time to try doing things nicely, in particular because the first steps and debug use allow you to do quick things.
But I don't think it's a fundamental property of IMGUI or Dear ImGui that "proper tools" become particularly more of a pain. Of course it is more work to make a proper tools than hasty-debug-tools, and I can easily see how underengineering can back-fire (over-engineering it likewise).
The purpose of an IMGUI is to handle whatever data retention will simplify user's life. If you want to extend the IMGUI in some case it's perfectly adequate to do some that work yourself. Ideally the IMGUI infrastructure would make it as painless as possible.
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.
So basically you are dismissing an existing definition to turn it into your own to say that existing libs are not fulfilling that definition.
But any effort to document, specs, clarify etc would be helpful and not just to Dear ImGui.
Accessibility is a whole world that is hard to grasp when you are not a end-user, API are large, confusing, poorly documented, and I presume that there are a large variety of tools and use cases and it's even hard to gauge what are the low-hanging fruits that would be the best to implement/bind.
Given how obfuscated Web stacks are nowadays (since they do try to prevent unauthorized scrapping and automation), I'm honestly also a little bit surprised that nowadays screen readers aren't relying on OCR more?
They are really cool/fun setup as well as being proofs of the portability of Dear ImGui but I imagine probably a little too taxing for the SoC involved. In the sense that if you were to want to use more of the SoC computational power it might feel like an unbalanced amount of resources to allocate to a GUI library (which normally expects a GPU).
I think it's a bit of both. From the point of view of game programmers and custom engine users/creators, it's important to know that Dear ImGui will be easy to integrate in whatever odd-custom tech they may have, and I am on the watch to hold that guarantee around, and to keep communicating it.
At the same time, effectively probably 90% of homebrew custom engines not build in a professional context are build over common known technology, Win32 API, SDL/GLFW, DX11 etc. And it makes sense to provide the ready-to-use glue to ensure you can integrate Dear ImGui is most apps with <20 lines of code. It's even more meaningful to have that possibility when you are bootstrapping a new projects or are wholly unfamiliar with programming or graphics technology.
The feature scope of Dear ImGui has grown meaningfully over the years, and although the only "required" elements are still mouse pos/buttons, time and rendering those vertices with scissoring, in reality there are many other desirable things which adds up to more work to provide (clipboard, keyboard, gamepads, mouse cursor shape, IME hooks, dpi queries, not mentioning multi-viewports).
You can see my reasoning for renaming examples/ to backends/ here: https://github.com/ocornut/imgui/issues/3513 If anything, I found the tendency of my-weekend-engine people to do their first foray into Dear ImGui often improductive and detrimental to the perception of using Dear ImGui. They tend to struggle 4 hours to get a feature-incomplete backends done instead of first plugging fully working existing backends with <20 lines THEN considering if they really need to rewrite that. I believe that did more bad than good to Dear ImGui because they end up using feature incomplete versions. It's also that years fixing those backends to try to have them work everywhere has been helpful in growing the confidence of calling them backends.
I believe this is mostly communication issue: we should keep hammering that backends are reasonably easy to rewrite and keep documenting that process.
Ref: https://github.com/ocornut/imgui/blob/master/docs/BACKENDS.m...
The vast majority is setting up SDL with a graphics context - anything graphics in C++ land is notoriously tedious, yes - not much of that is in control of Dear ImGui.
If you look at "Plugging Dear ImGui into SDL" there's a total of 14 lines involved in adding Dear ImGui over an existing SDL+OpenGL application, which is the precise target use of Dear Imgui.
Here are the lines:
// Init
IMGUI_CHECKVERSION();
ImGui::CreateContext();
ImGui::StyleColorsDark();
ImGui_ImplSDL2_InitForOpenGL(window, gl_context);
ImGui_ImplOpenGL3_Init(glsl_version.c_str());
// Event forwarding
ImGui_ImplSDL2_ProcessEvent(&event);
// New frame
ImGui_ImplOpenGL3_NewFrame();
ImGui_ImplSDL2_NewFrame(window);
ImGui::NewFrame();
// Rendering
ImGui::Render();
ImGui_ImplOpenGL3_RenderDrawData(ImGui::GetDrawData());
// Shutdown
ImGui_ImplOpenGL3_Shutdown();
ImGui_ImplSDL2_Shutdown();
ImGui::DestroyContext();
Yes, setting up graphics stuff in C++ is not trivial, but that's not Dear ImGui fault.
> Only a masochist would love this - which to be fair, probably describes game developers as a group.
Yes. Game developers are people who can have GTA5 running on a PS3, a console with 256x2 MB of RAM, while web applications displaying a chat frequently use more memory than that. I guess you call it masochist, I call it being efficient and excellent.
Yes indeed, it would be stupid for a text editor to force you to react on one million events or state changes. But this not how text editors are used. To use text editor in most case you only care about the text contents. Any other information is opt-in.
> And where do you store the complex state of the attributed text, or parsed source code in a code editor? Do you just pass the entire string in every frame and re-parse html each time?
You store it wherever you'd store it normally. Many of your question are assuming - and it's a misunderstanding - that IMGUI means that everything HAS to be recomputed every frame. What matters if the interface presented to the UI programmer. Of course the non-trivial text editor requiring a heavy parser, is going to store data if it needs to do so. What's the problem? Did you expect that IMGUI used zero-byte of memory and never store anything?
Text editor: https://github.com/ocornut/imgui/wiki/Useful-Widgets#text-ed...
> You can't just store that state in the actual objects you're showing in the outline, because that mixes your user interface layer with your data modeling layer.
Ever heard of data structures? You can associate data to an object given its ID without storing data inside the object.. This is what practically any advanced widgets in IMGUI land work. If you need 1 piece of data, use a dumb containers, if you need N pieces of data, use a map.
> And how do you implement efficient scrolling lists or tables or spreadsheets containing thousands or even hundreds of thousands of items? Do you have to pass every single item through the API every frame, instead of implementing callbacks to only pass and cache the items that fit on the screen?
You use a function call helping you to submit only items that fit on the screen. There's literally a helper for that in dear imgui. At this point I'm assuming you have never used what you are criticizing.
> And how do you implement graphics editors?
https://github.com/ocornut/imgui/wiki/Useful-Widgets#node-ed...
> Or drag and drop previewing? Or popping up item specific menus and submenus when you right-click on a list or outline item?
That's widely shown in the demo.
One of the benefit of IMGUI-style is to simplify user-data binding and avoid user-data sync/duplication, but that's entirely decorelated with layout consideration. You could perfectly have an editor manipulating widgets properties or their layout info (e.g. pos/size/anchor) somewhere and have the function fetch and use those infos.
If a widget exist in an user interface editor, regardless of the UI paradigm, some code will interact with that widget (read/write the data or bind actions to some callback). So what are you describing and what exists everywhere are merely a way to edit properties and layout, which can be done in IMGUI style, and actual binding requires code either way.
> or dynamically generate user interface resources from other programs.
Err... of course you can, and you are free to express them in whichever format is more adequate and convenient from your application. Generating user interface resources doesn't mean "generating code", that would be silly because the interesting part of that code is the data/function binding, and that's the one that makes less sense to magically generate.
> You can't iterate quickly on user interface development, because the user interface specification is a program that you have to recompile, not data that you can reload.
Then I'm sorry for you if recompiling and reloading code is a slow process in your workflow today. Many languages including C++ have hot-reloading techniques, and it is the standard for any so-called "scripting" languages like Python, Lua, Javascript to be easy to reload. _Because_ IMGUI have less state and less spread editing UI touches less code, less data structures, less layers and therefore it is easy to have that dynamic editing. With Dear ImGui I can add temporary tooling UI _inside a random function deep into the callstack_, reload the code while running, then remove that code when I'm done.
For a small developer I believe the whole topic seems quite overwhelming. To attract fringe GUI toolkits it would be useful to provide easy-to-chew accessibility samples based over 3d graphics technology (say: take a DirectX11 samples drawing a few text and buttons and make it accessibility compliant).
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.
You are comparing apple and oranges when comparing the feature set of a small UI system made by 1 person-ish vs something like Qt benefiting from decades of experiences and hundreds of devs.
For non-game (desktopey) app, well, there's no reason to render at 60 FPS you should only render on user interaction otherwise go idle most of the time....