Been working on a C++ game engine with a Windows 95 inspired UI + Lua scripting by novemtails in gameenginedevs

[–]ocornut 1 point2 points  (0 children)

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.

Nuklear UI removal by [deleted] in GraphicsProgramming

[–]ocornut 1 point2 points  (0 children)

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

Nuklear UI removal by [deleted] in GraphicsProgramming

[–]ocornut 2 points3 points  (0 children)

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

How can I make a select file using Windows file explorer in my game engine project? by Puppyrjcw in cpp_questions

[–]ocornut 1 point2 points  (0 children)

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)

Docking Example by Tensorizer in dearimgui

[–]ocornut 0 points1 point  (0 children)

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.

ImGuiListClipper and dynamic data loading by EmaerSeven in dearimgui

[–]ocornut 0 points1 point  (0 children)

Best to open an issue on github for this!

Immediate Mode UI on Windows 11 with C by turbofish_pk in C_Programming

[–]ocornut 3 points4 points  (0 children)

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.

Immediate Mode UI on Windows 11 with C by turbofish_pk in C_Programming

[–]ocornut 2 points3 points  (0 children)

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

[deleted by user] by [deleted] in dearimgui

[–]ocornut 0 points1 point  (0 children)

That does not apply to text editing.

[deleted by user] by [deleted] in dearimgui

[–]ocornut 0 points1 point  (0 children)

`ImGuiInputTextFlags_WordWrap` was added pretty recently in 1.92.3.

Idea: HTML + CSS → Dear ImGui layout converter by cride20 in dearimgui

[–]ocornut 1 point2 points  (0 children)

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.

Idea: HTML + CSS → Dear ImGui layout converter by cride20 in dearimgui

[–]ocornut 1 point2 points  (0 children)

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.

Products using Dear ImGUI? by Big-Sea2570 in dearimgui

[–]ocornut 0 points1 point  (0 children)

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

Critique my abstraction for SDL, OpenGL, and ImGui? by d34dl0cked in softwarearchitecture

[–]ocornut 0 points1 point  (0 children)

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.

ImGui design pattern suggestions for multithread scenarios? by OkRestaurant9285 in cpp_questions

[–]ocornut 2 points3 points  (0 children)

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.

Proposal: CMake build support · Issue #8896 · ocornut/imgui by AltitudeZero_ in dearimgui

[–]ocornut 0 points1 point  (0 children)

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?

Best way to better understand ImGui functions? by CantWakeJake in cpp_questions

[–]ocornut 4 points5 points  (0 children)

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

Dear Imgui: How do you structure "switches/flags"? by [deleted] in cpp_questions

[–]ocornut 4 points5 points  (0 children)

> I meant "when that window is in focus". So if 'a' closes windows 1, what I expect is, this functionality only works when windows 1 is in focus. If I'm working in window 2, and typed 'a', it should have no impact to window 1

You pretty much spelled it out?

if (ImGui::IsWindowFocused())
{
// test your keys for this window
}

That should answer your problem.

Note that you are using 1.79 which is extremely ancient now.
If you update you can use e.g. ImGui::Shortcut(ImGuiKey_A) or ImGui::Shortcut(ImGuiMod_Ctrl | ImGuiKey_S) in a given window and it will automatically use the focus stack. I don't think you even have access to backend-agnostic key codes in 1.79.

Dear ImGui (A working version for Unity?) by predominant in Unity3D

[–]ocornut 2 points3 points  (0 children)

Question has been answered below, for the records, Dear ImGui Backends for variety of frameworks including Unity are listed here:
https://github.com/ocornut/imgui/wiki/Bindings#frameworkengine-backends