MicroUI – A tiny, portable, immediate-mode UI library written in ANSI C

I made my own WASM demo @ https://microui-wasm.vercel.app/ and it's only 14.6 kB compressed!

Will share source code if someone is interested, but key bits:

- had a small JS glue layer using CanvasRenderingContext2D to render

- made a `wasm32-freestanding` build to lower the wasm bundle size, which meant shimming the bits of the libc microui uses

Why is the WASM demo so fuzzy? I am on Windows/Firefox.

https://imgur.com/uy78t52

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

I asked Claude to write one from scratch. A few minutes later it was done with exactly the features I needed. I started with some existing one, but when it couldn't handle multiple pointers (2 hands in VR/AR each with a pointer) without major mods I end up asking Claude if it could replace it with a custom one.

It first said "that's a ton of work" to which I said, "Really? A basic IMGUI needs a texture with glyphs. The abiltiy to draw textured rectangles with vertex colors. Scissor support for clipping. Some hit testing." and it was like, "yea, you're right", and a few mins later it wrote what I needed.

I'm not saying you shouldn't use this library.

The whole thing's less than 2kLoCs. If it needs ongoing maintenance, something's gone wrong IMO.

I think it's reasonable to just patch it yourself if it doesn't work with your other tools (Zig). Though thank you for sharing the heads up.

Genuine question; abandonware or complete? Something of this size serves as a nice substrate or starting-point regardless.

> it's kinda abandonware at this point

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

Raylib also has Raygui

https://github.com/raysan5/raygui

But I found it pretty straightforward (and satisfying) to just build my own gui functions/widgets with raylib (inspired by raygui).

https://github.com/dsego/strobe-tuner/blob/main/app/gui.odin

If that's your project, the Arabic text rendering is broken in this screenshot:

https://libagar.org/screenshots/agar171.png

"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/

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.

Everything is an engineering decision. Leaving out something doesn't mean it's a "toy". So, I don't really get your criticism here.

Windows XP has better accessibility than anything since, by virtue of staying entirely out of the way of accessibility tools. Time to downgrade!

Is there any game engine out there with good accessibility support for their UI?

What? On a micro immediate mode UI?

Really insane comment TBH

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

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).

Almost all of these immediate mode UI libraries for C/C++ come without a rendering backend. Usually there are "example" implementations for libraries like SDL that you can use, or you implement your own backend. A lot of these libraries are popular for debug UIs in games and you probably need a custom backend for whatever graphics engine you use in your game.

it's lighter weight and written in C

The problem is always: you don't know beforehand what bells and whistles you will need. That's why Qt is probably the only safe bet (or Web/Electron if you don't mind the slower performance).

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.

I was just thinking this would be great with go. If it would work.

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.