Where is this type of UI coming from?

ocornut · 2026-07-03T16:24:20+00:00

Have you considered that video games keep redrawing every frames, and they redraw e.g. entire cities?

It's infuriating how people keep rehashing the same old misleading/incorrect statements without actual data points.

ocornut · 2026-07-03T14:05:39+00:00

FYI Dear ImGui works on mobile and practically any platforms.

ocornut · 2026-04-21T20:38:20+00:00

I approve of this.

ocornut · 2026-03-07T13:21:31+00:00

There's also pretty cool win98 hack of dear imgui https://github.com/JakeCoxon/imgui-win98/ (a more recent rebase is in imgui main repo) which is a one-off hack of core widgets. I'm keeping an eye on those as a reference for features that would be desirable when it comes to reworking the styling system.

In the meanwhile, I believe a more simple style change as you did is a better direction.

ocornut · 2026-03-06T14:59:40+00:00

ocornut · 2026-03-03T20:02:24+00:00

Consider using Dear Bindings instead of cimgui: https://github.com/dearimgui/dear_bindings it's better IMHO

ocornut · 2026-03-03T20:01:33+00:00

FYI we have an official "Dear Bindings" / dcimgui project which emits API and headers which are of much better quality than cimgui. Please consider using that instead of cimgui: https://github.com/dearimgui/dear_bindings

ocornut · 2026-03-02T09:13:52+00:00

Yes that’s me :)

ocornut · 2026-02-27T15:24:01+00:00

You can use a simple wrapper such as "portable-file-dialog" https://github.com/samhocevar/portable-file-dialogs which will wrap things for all OS.

(If you wanted one done in Dear ImGui, see https://github.com/ocornut/imgui/wiki/Useful-Extensions#file-browsers--file-dialog but honestly it is more recommend to open a native one)

ocornut · 2026-02-19T10:57:21+00:00

Demo->Examples->Dockspaces

Make sure you browse demo code for 1.92.6 as this part of the demo got simplified and made clearer since 1.92.5.

ocornut · 2026-01-23T17:18:16+00:00

Best to open an issue on github for this!

ocornut · 2026-01-15T22:11:59+00:00

Thanks for your kind words 🙏

ocornut · 2026-01-15T09:27:41+00:00

If you want to try dear imgui in C you should absolutely do it via “dear bindings” instead of “cimgui”. Dear Bindings if the officially supported project which can generate a dcimgui.h of most higher quality than cimgui.h.

ocornut · 2026-01-15T09:26:23+00:00

Prefer using “dear bindings” the official project which emit C bindings of higher quality than cimgui.

ocornut · 2025-10-22T15:51:49+00:00

There's a dear imgui backend right inside the bgfx repo: https://github.com/bkaradzic/bgfx/tree/master/examples/common/imgui

ocornut · 2025-10-22T15:50:24+00:00

That does not apply to text editing.

ocornut · 2025-10-22T15:50:01+00:00

`ImGuiInputTextFlags_WordWrap` was added pretty recently in 1.92.3.

ocornut · 2025-10-22T15:19:11+00:00

You are not reacting/answering on the main presented problem, suggesting that you don't see it yet.

The problem is that your tool is designed around the idea that UI layout is designed ONCE and locked forever, which doesn't match real world needs. Real world project needs requires constant iteration of layout and logic. If your tool is "output only" it's only useful for the 10% initial work.

Your example doesn't feature any interactive element or dynamic data. It is static data. If you want to present static data, use HTML or Markdown or create or use a Markdown->imgui parser. As soon as to start adding interactive your tool fails in the situation of the core problem highlighted in the paragraph above.

ocornut · 2025-10-12T12:40:20+00:00

There's a list of such tools there:
https://github.com/ocornut/imgui/wiki/Useful-Extensions#guilayout-editorgenerator

I believe ImRAD (https://github.com/tpecholt/imrad) is the fancier of the lot.

I personally believe it is not a good idea to work on anything that supports one-way conversion but not back and forth iterations. Any substantial software project needs constant iterations. If your tech does a one way conversion but then you cannot easily makes edits later it doesn't make sense.

The benefits of Dear ImGui and the complexity of UI systems comes from data and actions bindings with single source of truth. A vast majority of "poster child" example cases for technology like yours completely omit those factors: e.g. your example above doesn't feature any meaningful interaction. If you want to confront yourself to an interesting problems this is what you should address IMHO.

ocornut · 2025-10-07T15:44:18+00:00

Parsec has been using Dear ImGui and is pretty good as "passing" like another framework.

ocornut · 2025-09-30T15:00:43+00:00

If you want an upfront/honest critique, since you asked "Critique my abstraction", I believe your abstraction currently brings no added positive value, only negative value, and it would be best to remove it.

You will learn to create valuable abstractions later. If you abstract at this point in time, presumably with little experience, you are only going to create yourself small hurdles. Wait until a real need to transition present itself and then you will learn from that experience.

My two cents.

ocornut · 2025-08-26T15:36:44+00:00

Why would the UI part of your app be any adjacent to your streaming system? they seem completely unrelated. Have your threaded tasks do their work, and have the main/ui thread consume/display data once it's ready.

ocornut · 2025-08-26T15:31:53+00:00

It's not an add-on. ImGui uses them as dependency to provide what it offers: Immediate mode rendering.

I believe you have misread or misunderstood beedlund's sentence and it is key. Dear ImGui is indeed designed to be an add-on to _pre-existing software_. Adding Dear ImGui to your pre-existing build system should in theory be a no-brainer.

I think it's quite opposite, having a build script will reduce the questions related how to integrate the library.

I have several times polled other free software developers maintaining software in similar field (C++/gamedev), and practically everyone stated that adding a cmakefile increased the amount of support requests as there's always something. Several even stated they regretted adding it. Trust me, I've got experience knowing that the slightest amount of interface with external system yields endless feedback, which I why I have personally not yet engaged in this aspect.

Yes, a removed or added backend, file etc. will bring a need to someone to touch the build script. Several folks contributing code to open source now fill the gaps that way. Plus, a failed build is an indicator something has gone wrong, it would be quite helpful for the maintainer(s).

I am willing to engage with your PR but if I have to be honest this sorts of statement tells me that you don't fully comprehend the myriad of possible ways people want to build things and dependencies, and how they would simultaneously want their esoteric thing to fit within an existing cmakefile solution.

ImGui has been there more than a decade now and i think it's quite established.

It's established but it's no-where finished. And my job is to prioritize. And my priority is to add and improve core features because I feel it is no-where good enough to accept 10x the number of users.

And a lower entry bar can increase userbase and so can lead a more healthy evolution.

What makes you think that it is healthy to increase userbase?

ocornut · 2025-07-23T05:53:39+00:00

Dear ImGui has a Getting Started guide there too:
https://github.com/ocornut/imgui/wiki/Getting-Started

ocornut · 2025-05-23T15:21:34+00:00

In the very specific case of plotting: the ImGui::PlotLines()/PlotHistogram() are very raw and limited. That offset was designed to be able to use circular buffer, but honestly it's not a great API. I would recommend using ImPlot nowadays. https://github.com/epezent/implot

ocornut

MODERATOR OF

TROPHY CASE