pretty nifty but im trying to figure out what the use case for this is when its aimed at hobbyists ?

I use pygtk and dont have to fiddle with lower level stuff

> it's kinda abandonware at this point

That's sad. I'm a fan of rxi's work, including this one.

"Accessibility" is an open-ended set of functionality, not a checkbox; it is never "complete", there is always room for improvement. Colorblind support (which ones)? High-Contrast mode? Adjustable text size? Screenreader integration? Localization? IME support? Keyboard navigation? Keyboard remapping? Functional entirely without a keyboard? Touch support? Pen support? Dyslexia-aiding typefaces? The list goes on and on.

No. As much as I would like it to be the case, that is most certainly a poor criteria to evaluate a UI library.

Dear ImGui [0] is without a doubt the most prevalent immediate mode UI library. It does not have native accessibility features, but that hasn't stopped companies such as Intel, Meta, IKEA and Google from shipping products built upon it. It's also used in a ton of games.

Calling Dear ImGui a toy project at this point would be like calling Unreal Engine a toy project.

It's a shame accessibility support is not more widespread, and furthermore it's a shame that it is so laborious to add it.

0: https://github.com/ocornut/imgui/

I agree, and the lack of empathy around this area is sad. If you're developing an app, it is better to fall into the pit of success by using a UI framework that already has accessibility baked in. Any project that uses Dear Imgui for end-user applications has already made a bad design choice. AccessKit (https://accesskit.dev/) seems to be a positive step forward, with some UI frameworks implemented (including immediate mode egui).

This is a library in similar vein to "Dear imgui", minimal requirements for integration (rectangle and text rendering) so that it's easy to embed into game-engines,etc for debug UI's and similar things.

Not very smart. I would go further and say that even full unicode support could be avoided and a software can still be massively useful.

It is sad that the world is so hung up on unicode and things like accessibility that we all have to submit to the tyranny of browser layers!

Or, not every UI library is intended for use cases where a13y even makes sense.

Like a debug UI in a game engine, or in an embedded device that doesn't even have input for a13y.

What? On a micro immediate mode UI?

Really insane comment TBH

Then just save yourself some time. Immediate mode and accessibility are mutually exclusive.

it's lighter weight and written in C

Very different, starting at the line count:

Lvgl is 440kloc across 1134 files (in the src directory), while microui is 1121 lines of code in one .c and one .h file.

Microui is immediate mode, very minimal and 'bring your own renderer'. Probably most useful for adding a small debugging UI to a 3D game/app.

That's the whole point!

You plug it into your project and it can be rendered on anything that can push pixels and/or triangles to the screen. Events from windowing system go in, list of triangles comes out.

This is intended to be used with OpenGL, Vulkan, D3D and other graphics environment and used in cases where integrating a "real" GUI toolkit would be more trouble than it's worth.

Other popular libs like Dear Imgui or Egui work the same way.

It's a "bring your own renderer" UI framework, just like Dear ImGui or Nuklear. In some situation (e.g. when adding debugging UIs to a game) this is actually a big advantage compared to the renderer being baked into the library, since the game already has a renderer subsystem which the UI can easily hook into.

In demo/ someone can "steal" the renderer part which, being based on SDL, is to some extent cross-platform.

The demo uses a simple prebuilt fixed-size font atlas texture and renders the entire UI (including character quads) via batched glDrawElements calls (one draw call per clip-rect).

But the way how text rendering is delegated to the user is quite flexible, microui basically calls these three user-provided functions:

    int r_get_text_height(void)
    int r_get_text_width(const char* text, int len);
    void r_draw_text(const char* text, mu_Vec2 pos, mu_Color color);

it does not, it basically delegate that part to lower level library for which you have to write the glue code for, there is an example for SDL.