cppwin32 VS imgui

I would imagine something like https://github.com/microsoft/cppwin32 would maybe be an easier way forward for that?

no, Microsoft has rewritten the windows API in C++ I think https://github.com/microsoft/cppwin32

An official work in progress Windows binding, still far behind of what C# existing bindings are capable of, or legacy toolkits like MFC.

Also given how the team has managed C++/CX transition to C++/WinRT with lesser tooling stuck on C++17, dropped Modern C++ bindings [0][1], before going into other shinny thing, I wonder how long they will keep at it.

[0] - https://blogs.windows.com/windowsdeveloper/2021/01/21/making...

[1] - https://github.com/microsoft/cppwin32

If you want to use the old tooling, your C++ is going to be very "C with classes," and it's going to use a lot of weird datatypes that don't feel very C++ at all. Microsoft had a project for wrapping the Windows API in idiomatic C++, but appear to have abandoned it. If you choose to go down this road, Charles Petzold's Programming Windows is the book to get. Yes, it's 25 years old, but all the new stuff is just new COM controls (which you can look up in the API documentation)--the fundamentals of making a Windows API program work seriously have not changed.

Even Rust has a native projection of the windows API (which is actually pretty usable). This projection has the same roots as the C++ projection mentioned by u/amnesiac0x07C5. So I don't believe macros are a blocker here.

See : https://github.com/microsoft/cppwin32

Microsoft have recently put decent effort into making the Windows APIs more accessible to C++ users. One of these efforts is called C++/WinRT, and it specifically targets applications intended for "modern" Windows (Windows 8 and later). There's another effort underway at Microsoft for making the older Win32 API more C++-friendly, but it isn't documented nearly as well.

There is a similar project for C++, but it sadly seems to be dead already. The last commit was one year ago.

not that hard to wrap windows.h and undef the annoying stuff, and only a handful of files in your codebase will include it anyway. on the other hand stuff like this looks extremely worse and exactly like the kind of c++ that is hard banned in gamedev codebases

They are, actually, it's linked from the article: https://github.com/microsoft/cppwin32

include(cmake/CPM.cmake) function(raylib_imgui_setup_dependencies) message(STATUS "Include Dear ImGui") FetchContent_Declare( ImGui GIT_REPOSITORY https://github.com/ocornut/imgui GIT_TAG 277ae93c41314ba5f4c7444f37c4319cdf07e8cf) # v1.90.4 FetchContent_MakeAvailable(ImGui) FetchContent_GetProperties(ImGui SOURCE_DIR IMGUI_DIR) add_library( imgui STATIC ${imgui_SOURCE_DIR}/imgui.cpp ${imgui_SOURCE_DIR}/imgui_draw.cpp ${imgui_SOURCE_DIR}/imgui_widgets.cpp ${imgui_SOURCE_DIR}/imgui_tables.cpp) target_include_directories(imgui INTERFACE ${imgui_SOURCE_DIR}) include(cmake/CPM.cmake) message(STATUS "Include dbg-macro") cpmaddpackage( "gh:sharkdp/dbg-macro#fb9976f410f8b29105818b20278cd0be0e853fe8" )# v0.5.1 message(STATUS "Include fmtlib") cpmaddpackage("gh:fmtlib/fmt#e69e5f977d458f2650bb346dadf2ad30c5320281" )# 10.x message(STATUS "Include raylib") cpmaddpackage("gh:raysan5/raylib#ae50bfa2cc569c0f8d5bc4315d39db64005b1b0" )# v5.0 message(STATUS "Include spdlog") cpmaddpackage("gh:gabime/spdlog#7c02e204c92545f869e2f04edaab1f19fe8b19fd" )# v1.13.0 message(STATUS "Include rlImGui") FetchContent_Declare( rlImGui GIT_REPOSITORY https://github.com/raylib-extras/rlImGui GIT_TAG d765c1ef3d37cf939f88aaa272a59a2713d654c9) FetchContent_MakeAvailable(rlImGui) FetchContent_GetProperties(rlImGui SOURCE_DIR RLIMGUI_DIR) add_library(rlimgui STATIC ${rlimgui_SOURCE_DIR}/rlImgui.cpp) target_link_libraries(rlimgui PRIVATE imgui raylib) target_include_directories(rlimgui INTERFACE ${rlimgui_SOURCE_DIR}) endfunction()

Immediate mode is a fuzzy concept, as witnessed by this writeup: https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi...

It's fun to see the evolution in e.g. these examples of image loading for Dear Imgui:

https://github.com/ocornut/imgui/wiki/Image-Loading-and-Disp...

DirectX9 will even load the image for you, DirectX11 okay we get a few more structures to fill out, DirectX12 is where it goes off the rails and we are filling out a bunch of UNKNOWN DONT_CARE JUST_DO_IT. Then of course Vulkan is the one that gets the big fat "this probably won't actually work for you" warning.

I understand whats happening, but you know sometimes I just want to display a fucking image.

ImGui is engine/GPU agnostic

Themeing isn't a just a retained mode thing, you can do wonders with immediate UIs, even thought (dear)ImGui doesn't provide much, you can still do wonders: https://github.com/ocornut/imgui/issues/707#issuecomment-362...

More on that topic: https://www.youtube.com/watch?v=Z1qyvQsjK5Y

Bonus: If you want to make desktop app with UI, then this is another great C++ library and it's also simple to learn as well. https://github.com/ocornut/imgui.

AFAIK the Rust equivalent to C++'s Dear ImGui is egui.

They use a Dear ImGui, a C++ GUI library.

Aside from bugs and driver issues, Wayland has some unfortunate design limitations. For example, Dear ImGui multi-viewports don't work because "Wayland doesn't let application read or write windows positions."

https://github.com/ocornut/imgui/wiki/Multi-Viewports

This is a feature available on Windows, macOS, and of course X11. Making choices like this means desktop Linux becomes even more of a weird island that nobody wants to support.