egui VS imgui

Anyone who's interested in the AccessKit integration can play with my work-in-progress branch: https://github.com/mwcampbell/egui/tree/accesskit

It's currently Windows-only, and I'm working on the big missing feature, which is text editing support.

> A core premise of Cocoa, and MVC in general, is that UIs are a projection of data into a different form of data, specifically bits on a screen.

This is a tangent, but the implicit assumption that the UI is visual is just begging for a response from an accessibility perspective, so here goes.

Accessibility is very much an afterthought in native GUIs, not only in Cocoa, but also in Windows with the UI Automation API, and AFAIK with other native accessibility APIs as well. With these APIs, the assistive technology (e.g. screen reader) pulls information from the application (usually via the GUI toolkit), through repeated calls to methods defined by the accessibility API. Often the AT has to do several such calls in a row (and those often translate to multiple IPC round trips, making things slow). And the UI might change between such calls; there's no guaranteed way to get a consistent snapshot of the whole thing, as there is with a visual frame. On the application/toolkit side, these methods may return different responses from one call to the next, and the application or toolkit has to fire the right events when things change.

The web improves on this, in that accessibility information is conveyed through HTML tags and attributes. And yes, this is included in the output of a React component's render function. So while in practice, implementing accessibility may still be an afterthought, it's not an architectural afterthought as it is in native platforms.

One of my goals in AccessKit [1] is to work around this shortcoming of native accessibility APIs, particularly for developers of cross-platform non-web GUI toolkits. In AccessKit, the toolkit pushes a full or incremental accessibility tree update to the AccessKit platform adapter, which maintains the full tree in memory and uses that to implement the platform accessibility API. This even works for immediate-mode GUIs, as one can see in my proof-of-concept integration with the Rust egui toolkit [2].

[1]: https://github.com/AccessKit/accesskit

[2]: https://github.com/mwcampbell/egui/tree/accesskit

I can also report some modest progress on my own work on accessibility of immediate-mode GUIs. I have a branch of the Rust egui library [1] that has basic accessibility on Windows using my AccessKit project [2]. I do have a long way to go to make this fully usable and ready to submit upstream, especially when taking non-Windows platforms into account.

[1]: https://github.com/mwcampbell/egui/tree/accesskit

[2]: https://github.com/AccessKit/accesskit

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.