electricui-embedded VS imgui

We have an MIT licensed protocol and Arduino library that makes it really easy to transfer data to the UI, and components for real-time line or scatter plots.

It includes an MIT licensed binary protocol that handles framing, checksums and multiple messageIDs. Standard C types are zero-configuration, just send them from hardware and the UI knows how to decode it. You can mark variables with some macros and get read/write capability in very little code. Assuming you're communicating over usb-serial, it should be very easy to get started. Here's the 'Arduino blinking led' firmware as an example.

We have an MIT licensed protocol and Arduino library, which provides framing, checksums, multiple messageIDs, query / set / call function behaviour, type information, ack packets, 1kB payload sizes by default and offset packets for sending larger data. There's a write up of the protocol here. I'm unsure how you've developed your stand alone program, but if you implement the 'host' side of the protocol, the Arduino library will take care of everything else.

If it's just the protocol you want, we have an open source, MIT licensed protocol available on GitHub. It comes with an Arduino library that you can install in a couple of clicks.

As a continuation of my other comment, Electric UI's binary protocol makes sending different data at different intervals pretty trivial. It's intended for serial comms, but of course can be sent over ethernet just as well.

It has an MIT licensed binary protocol that handles framing and checksums which works well over serial. There are several Arduino firmware examples in that repo.

While it is transport and protocol agnostic, it comes with a 'batteries included' binary protocol for serial comms to get up and running quickly. The protocol handles framing, multiple message IDs, acks and checksums.

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.