ImFrame VS imgui

If you need a quick way to start a C++ ImGui app, you can use my ImFrame library. It's essentially a C++ application wrapper around glfw + ImGUI, along with a few handy additions that applications might need, like native file and folder dialogs, automatic windows settings / persistence, etc.

If you want a demo, you can use my starter framework to see if it would work for you, or check out Implot's repository directly.

If you want a Dear Imgui "starter kit", you can try ImFrame. It packages a few libraries into a very lightweight cross-platform application framework.

If you just want an empty app in which you can play with ImGui, you can use a lightweight framework like ImFrame.

To help with this, I made a framework that makes it much easier to use like a more traditional application framework, providing a few handy features you'd expect, like native file dialogs, window position save/restore, native macOS windows, platform-appropriate settings storage, image loading, a selection of fonts, etc.

Probably the fastest way to do that is to use something like my ImFrame library, which is designed to get Dear ImGui and ImPlot up and running inside an app with minimal fuss and bother. You'll need to use CMake to build the project, but it's pretty simple, as there are batch files to build in the /Bin folder for Windows, Mac, or Linux.

Dear ImGUI - Unlike the others, is designed for applications with a real-time rendering loop, such as games. Was originally designed for creating debugging UIs, although has expanded far beyond this, and is now used for full-featured applications. Requires an existing back-end to plug into. If you need an application framework for Dear ImGUI, you can use my own project ImFrame, or something similar.

I use CMake as my (meta) build system, and generate VS projects on Windows, Xcode projects on Mac, and Code::Blocks projects/makefiles on Linux. Example of one such project of mine: https://github.com/JamesBoer/ImFrame

I'm currently writing a Dear Imgui framework called ImFrame. It handles the work of creating an application loop with an appropriate renderer, using GLFW and other open source libraries, and then exposing the Dear Imgui API for your use to do what you want with it.

For example, in one of my libraries (you can see the whole thing here), I'm including the single-header library stb_image.h as a separate project, so it shows up with all the other external libraries. It's not necessary for compilation, but is just there to assist with browsing / seeing all the external libraries.

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.