flohofwoe3 hours ago
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
zuzululu2 hours ago
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
flohofwoe2 hours ago
Minimal debugging/controller overlays for games would be the most obvious use case (e.g. similar to dat.gui for web).
kartoffelsaft4 hours ago
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.
packetlost3 hours ago
> it's kinda abandonware at this point
That's sad. I'm a fan of rxi's work, including this one.
haeseong4 hours ago
[flagged]
jaceredaan hour ago
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.
jmiskovican hour ago
kettlez3 hours ago
This is included in the Odin vendor libraries, it's fantastic for Raylib debug menus
abtinf5 hours ago
The first thing I look for in any UI library is accessibility support. Makes it trivial to filter out toy projects.
RodgerTheGreat5 hours ago
"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.
Dwedit4 hours ago
One clearly defined starting point is exposing any custom controls to accessibility APIs that are used to enumerate and interact (simulated mouse actions, reading the text, etc) with controls on the screen. Both scripting tools and screen readers make use of these. Built-in controls already have the enumeration and interaction feature and don't need additional code, but custom controls may not have that.
In the MicroUI example here, there are buttons and text labels and other kinds of controls, but no ability for an outside process to enumerate or interact with the controls. Any program will just set a single giant window with no text and no controls inside. Accessibility software can still hook text output APIs, but not if it also uses custom font rendering.
Anyway, the Windows accessibility API is just implementing a few COM objects, and COM (other than the specific ABI used for storing the vtable and function call convention) is not necessarily specific to Win32.
jazzypants4 hours ago
This is one of the reasons why web technology is so popular and persistent. You get almost all of that for free as long as you use semantic HTML.
LtWorf2 hours ago
Which nobody uses
xyzzy_plugh5 hours ago
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.
whizzter5 hours ago
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.
SeasonalEnnui2 hours ago
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).
qsera3 hours ago
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!
anonymous908213an hour ago
> sad that the world is so hung up on unicode
It is sad that the world is hung up on enabling 2/3rds of the world population to read and write text! If only the entire world catered to America. Nobody should ever speak anything other than English, honestly.
monocasa5 hours ago
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.
fwip3 hours ago
Being accessible to the intended users always matters. If you think it doesn't, that probably means it's currently accessible to those users (or that those who are it is inaccessible to have filtered themselves out, and are no longer users).
For example - in your debug UI, colorblind-friendly colors don't matter, until you hire your twelfth member of the team, who struggles to tell red and green apart.
monocasa3 hours ago
This library's default is greyscale anyway, so it's by default colorblind friendly.
jdmoreira4 hours ago
What? On a micro immediate mode UI?
Really insane comment TBH
dwb3 hours ago
The point of a UI library is to interface with users. If it totally fails to interface with a subset of users then it is obviously deficient to some degree. It is callous and foolish to dismiss offhand users who rely on assistive technologies. You probably have a poor idea of who they are and how many people we’re talking about. You never know when you or someone you care about will become one of them, even temporarily. You never know how far your software will reach when you write it.
spwa45 hours ago
Then just save yourself some time. Immediate mode and accessibility are mutually exclusive.
afavour4 hours ago
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.
OvervCW4 hours ago
What is the advantage of this compared to Dear Imgui?
ranger_danger4 hours ago
it's lighter weight and written in C
synergy204 hours ago
how is this different from lvgl? is this immediate mode or retained mode?
flohofwoe2 hours ago
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.
ur-whale5 hours ago
Nice, except the hard part seems to be missing: interfacing with an actual window system (X11, TUI, WIN32, whatever ...)
exDM695 hours ago
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.
flohofwoe2 hours ago
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.
foul5 hours ago
In demo/ someone can "steal" the renderer part which, being based on SDL, is to some extent cross-platform.
peter_d_shermanop6 hours ago
>"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"
Littice6 hours ago
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.
flohofwoe2 hours ago
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);
dvhh3 hours ago
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.