37 comments

[ 0.25 ms ] story [ 49.9 ms ] thread
>"Features

o Tiny: around 1100 sloc of ANSI C

o Works within a fixed-sized memory region: no additional memory is allocated

o Built-in controls: window, scrollable panel, button, slider, textbox, label, checkbox, wordwrapped text

o Works with any rendering system that can draw rectangles and text

o Designed to allow the user to easily add custom controls

o Simple layout system"

Immediate-mode in pure C is a nice constraint. how does it handle text rendering, do you bring your own atlas or is there something built in? Thats usually the part that balloons the dependency footprint.
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.
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);
...how r_draw_text() is implemented is then entirely up to you.
Nice, except the hard part seems to be missing: interfacing with an actual window system (X11, TUI, WIN32, whatever ...)
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.
The first thing I look for in any UI library is accessibility support. Makes it trivial to filter out toy projects.
What? On a micro immediate mode UI?

Really insane comment TBH

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!

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).
Is there any game engine out there with good accessibility support for their UI?
Windows XP has better accessibility than anything since, by virtue of staying entirely out of the way of accessibility tools. Time to downgrade!
Everything is an engineering decision. Leaving out something doesn't mean it's a "toy". So, I don't really get your criticism here.
how is this different from lvgl? is this immediate mode or retained mode?
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.

This has been my goto for personal toy projects for a while now. Trivial to slot in to basically anything that can display text and takes mouse input.

I will mention, however, it's kinda abandonware at this point. There is some bug with the draw call iterator which does a misaligned pointer access, which, if your environment is set up to catch that, can get annoying (Zig for example panics on it). There's a github issue that some have used as reason to fork it but all the forks I tried were subtly wrong, for what that's worth.

> it's kinda abandonware at this point

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

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

And that's okay(tm).

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.

Cool to see a demo in there that you can run in a browser, presumably compiled to WebAssembly. The kind of thing that was unimaginable years ago.
What is the advantage of this compared to Dear Imgui?
This is included in the Odin vendor libraries, it's fantastic for Raylib debug menus
I wrote a little demo to run microui on top of the sokol headers here, it's really interesting in how minimal it is.

WASM demo: https://floooh.github.io/sokol-html5/sgl-microui-sapp.html

Source code: https://github.com/floooh/sokol-samples/blob/master/sapp/sgl...

The renderer backend is just a bunch of C functions you need to provide:

https://github.com/floooh/sokol-samples/blob/3f4185a8578cd2b...

It's also interesting to compare the binary sizes:

microui sample (https://floooh.github.io/sokol-html5/sgl-microui-sapp.html): 79.6 KBytes compressed download

Nuklear sample (https://floooh.github.io/sokol-html5/nuklear-sapp.html): 155 kb compressed download

Dear ImGui sample (https://floooh.github.io/sokol-html5/imgui-sapp.html): 491 KB compressed download

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.

I used this one in 2022 to make a proof of concept for a build once / run anywhere graphical app and IIRC the library was quite nice, even if a bit limited. The resulting kludge is at https://github.com/jacereda/cosmogfx and there's a prebuilt binary that should run on Linux, Windows and some BSDs. https://github.com/jacereda/cosmogfx/releases/download/v0.0....

Cosmopolitan Libc has since integrated the bits to make OpenGL work in cross-platform binaries and it's awesome.

anyone working on bindings to other languages? (go, python, ruby, etc)
love the web assembly demo. By the way, I hope this kind of interface for the web becomes more mainstream in the future, I start to hate html / css cuz everything looks the same because of it (even in the train stations they use it for scheduling)
How can such a library be both tiny and portable, when the C standard library has no graphics facilities? Don't you need to lay down a lot of basis for different platforms and graphics backends, to be portable? And if you do that, how can you be tiny?
I need something like this but with a few more bells and whistles.
For a slightly larger, cross-platform, retained mode GUI written in C, there's libagar [0]. Different use case than MicroUI, but still a neat project.

[0] https://libagar.org/

this is easy

question is how produce sms-message like text widget, with alligment like iphone