Dear ImGui Updates: v1.89.8 Release / Docking Branch

[richardeakin]

This updates Dear ImGui sources to v1.89.8, docking branch. Also hoping to get a consensus on what branch people would like to see in the master repo. Personally, I think the new ImGui Tables API is a must for data debugging, although that does live in the official release branch. I know that on various client projects, we've switched to using docking as it allows for a cleaner user-facing GUI, and although the API appears stable who knows when it'll make it into the official release branch.

Important code changes include:

• imgui_tables.cpp is new
• imgui_impl_opengl3_loader.h is new but kept private to src folder (gl loader only used by imgui_impl_opengl3.cpp)
• Using CinderImGuiConfig.h now
  • It was already in the cinder repo, just wasn't being #includeed.
  • Fixes IM_ASSERTS not being catchable
  • defines IMGUI_DEFINE_MATH_OPERATORS (see release notes in v1.89.4)

I had to make minor upates to my own GUI code in various places (ListBox(), GetContentAvailWidth() -> ImGui::GetContentRegionAvail().x)

Last thing to note: we're discussing moving Dear ImGui to a submodule for a future release (likely when v2.0 lands), let us know if any feedback on that as well.

Needed:

• add imgui_tables.cpp to the Xcode project. I don't have access to an OS X machine right now. This is why the unit test is only failing on the OS X target (cmake is looking for imgui_tables.cpp already)

[richardeakin]

I just pushed an additional update that fixes IM_ASSERTs called from within imgui.cpp, imgui_widgets.cpp, etc, that don't include CinderImGui.h first. Tested and breakipoints now get correctly routed to CI_BREAKPOINT(), and you can use things like LoggerBreakpoint() now to hunt down a missing ImGui::End(), for example.

This is because if the user doesn't define IMGUI_USER_CONFIG, CinderImGui.h will include its own config header called "cinder/CinderImGuiConfig.h". But imgui.h is written so that if IMGUI_USER_CONFIG isn't defined, then it will #include "imconfig.h", here. Two other ways we could fix this:

• Define a IMGUI_USER_CONFIG = "cinder/CinderImGuiConfig.h" macro for cinder targets, on each platform (msvc, xcode, cmake).
• Move the contents of our CinderImGuiConfig.h to imconfig.h and just keep imconfig.h. Drawback is updating would wipe out the cinder mods for our types and handlers if you're not careful.

I think this is a decent middleground, where all you need to do after updating, is to copy that #include redirect so that imgui.h and everything else is looking at CinderImGuiConfig.h, which is versioned in the cinder repo.

[Segfault1602]

Thank you for working on this! Hard to see looking at the diff, but did you need to modify any of the Imgui sources?

Regarding submodules, I don't know how that would work with Tinderbox, but I've had a good time using CMake's FetchContent to include ImGUI. I think this might make it easier for people to update ImGui on their own. However, this won't work if the ImGUI source needs modification prior to integration.

[richardeakin]

Didn't have to modify Dear ImGui sources, just a small bit of Cinder's wrapper to use CinderImGuiConfig.h.

I don't think we can rely on a CMake specific tool to download ImGui because CMake is just one way we build cinder and samples. In production work, we usually use the hand-tuned Visual Studio project files directly. We could write scripts to fetch ImGui sources, though I personally feel that route is tedious to maintain and as we already use submodules for other things (Tinderbox and usually much more in production projects), they are still the easiest and most flexible way to go.