ocornut

The copy in dear imgui sources has a few tweaks to make it possible to use with UTF-8 without unnecessary lookups: see `STB_TEXTEDIT_GETPREVCHARINDEX`,`STB_TEXTEDIT_GETNEXTCHARINDEX` and `stb_textedit_text()` use.

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.

It baffles me that any maintainer would merge code like the one highlighted in the issue, without knowing what it does. That’s regardless of being or not being able to see the “invisible” characters. There’s a transforming function here and an eval() call.

The mere fact that a software maintainer would merge code without knowing what it does says more about the terrible state of software.

Specifically for panning and zooming, doesn't the OS translate those inputs to mouse events, like Windows does by default? Otherwise it is simply a matter of performing this translation at the backend level.

I promise it’s coming eventually but I don’t believe the custom version is hard to make to work either.

The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement:

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.

You can manually transform vertices (call ImGui::ShadeVertsTransformPos) this is what angled headers are using https://github.com/ocornut/imgui/issues/6917 I agree it's not first-class citizen yet, next year new text API should make this easier.

It's my github post and I wanted to post it on HN but being new to this I was surprised that submitting my link merged it to an existing post.

Dang you posted faster than I did :) Thanks!

I am not saying it is a silver bullet.

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.

But as soon as it stops being just hacky debuggers and people try to write proper tools in it, it becomes much more of a pain - people try to (poorly) emulate a retained mode in it, hold state, cache - and it becomes unreadable mess.

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

That seems really hard to achieve in immediate mode libraries without effectively recreating retained mode functionality yourself.

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 even has an option to limit the FPS, which solves the CPU load a bit, but at the same time results in sluggish input because the event handling is tied to the drawing frequency.

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.

The person who coined the IMGUI term (Casey Muratori) literally defined "immediate mode gui" as a concept relating to the API/facade, regardless of what the UI system internally owns or store or manage.

So basically you are dismissing an existing definition to turn it into your own to say that existing libs are not fulfilling that definition.

Dear ImGui is lacking good and focused code contributors, I'm stretching myself quite thin already and unfortunately pragmatically it currently wouldn't be wise for me to attempt working on accessibility features :( Right now the state of things is that a majority of even the simplest PR are poor quality, so I'm not too hopeful that such a complex feature would magically start getting good contributions. I am personally just accepting that things are going to take years to move forward. I'd rather have them more slow and stay sane. Dear ImGui is intentionally gated and made fugly for those reasons as well.

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?

Good Testing/Automation is never free lunch AFAIK but Dear ImGui has a testing/automation system: https://github.com/ocornut/imgui_test_engine

Also see the interactive web manual https://pthom.github.io/imgui_manual_online/manual/imgui_man...

There’s no caching. Most people advocating or theorizing about caching haven’t measured the performances of dear imgui or implot. Computers are incredibly powerful when you don’t waste their resources.

Also try mouse-wheeling in Tracy web version (using Dear ImGui) and opening different panels: https://tracy.nereid.pl/ I think you'll find it to be more reactive and snappier than most traditional toolkits.

Interestingly there are no modification of the core Dear ImGui library involved. It's using a software renderer, which have been available already e.g. that one had been optimized to run on ESP32 https://github.com/LAK132/ImDuino

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 picked your write-up on that unstructured attempt of making a page of definitions: https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi... Thanks!

Hi gregg :)

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

You can feel this persons frustration about all the obscure magic incantations needed to get a simple GUI and some lines on screen.

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.

https://www.youtube.com/watch?v=d0KJhFMnWRI

Where do you draw the line? Some companies are using it for polished large tooling which may have thousands of end-users. Those users will eventually want a solution to tackle that.

Sure, a button function that returns a boolean can be used as a simple parameter to an if statement, but you would would need a switch statement to test for all the different events that a text editor could send. That's a terrible clumsy API!

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.

The vast irony of all this is that today interacting/scrolling in Facebook or Twitter is vastly less efficient that a basic graphic app rendering at 60 FPS. Facebook has become _ACTUALLY_ slow to interact with even from a human point of view.

That's not true.

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.

Hello Matt,

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

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.

I'm not sure I understand why you think there is no way to do that with an API designed in IMGUI style? IMGUI is a style of exposing UI API. There's no reason this can't be made with a IM-style UI.

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.

As mentioned the cost is negligible when you already have a animated 3D scene with the case for games.

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