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
Narishma 12 hours ago [-]
Your demo seems to constantly consume 100% CPU at all times.
onsclom 12 hours ago [-]
Ooh interesting. What is your machine and browser? On chrome with my m1 macbook it takes less than 1ms to compute and render each frame, but I am noticing some things I can optimize from the performance flame graph! I will say, I find chrome to be way more efficient for ctx2d things than firefox or safari.
Lockal 2 hours ago [-]
Chrome on Linux suffers from this too. The issues are standard for all naive immediate GUI libs:
- some libs can skip repaints but have no concept of damage area
- bad handling of high-dpi (which also can change dynamically)
- constant repainting behaves even worse on laptops which announce 180 Hz refresh interval, which means that it drains the battery 3 times faster than 60 Hz
This doesn't explain a 100% CPU usage, especially not for such a simple demo. The entire per-frame load should only be a tiny fraction of a frame duration.
Narishma 9 hours ago [-]
Firefox on Linux.
starik36 11 hours ago [-]
Why is the WASM demo so fuzzy? I am on Windows/Firefox.
TL;DR: it can be all sorts of things, from 'half-pixel' positioning problems, to upscaling issues, to poor source data. I didn't put too much effort into getting the text rendering look good (and text rendering is hard).
More details:
The demo is using half-resolution on high-dpi displays (currently that's sokol-app's default setting, but not sure if that still makes sense in this day and age tbh), this half resolution amplifies all sorts of text rendering issues, and it gets especially bad when there's a fractional system-dpi-scale like 125% or 150%.
PS: another problem (maybe the main problem, even if everything else is correct) is that the demo's pre-baked font atlas texture isn't all that great since it has 'anti-aliasing' baked into the glyph pixels, and the font atlas texture has a very low resolution (glyph height is 10 pixels, which would be ok for a 'crisp' hand-drawn bitmap font, but not when the font atlas has been created from a regular TTF font, which this one seems to be).
Does this Dear ImGui demo look better on your setup? This is using the native display DPI and uses a TTF font instead of a bitmap font:
Looks like the rendering functions used in the demo are doing antialiasing without font hinting?
zuzululu 20 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
flohofwoe 20 hours ago [-]
Minimal debugging/controller overlays for games would be the most obvious use case (e.g. similar to dat.gui for web).
Levitating 15 hours ago [-]
pygtk requires GTK, this library works with any rendering library that can draw rectangles and text
socalgal2 6 hours ago [-]
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.
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.
leecommamichael 15 hours ago [-]
Genuine question; abandonware or complete? Something of this size serves as a nice substrate or starting-point regardless.
Intralexical 14 hours ago [-]
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.
packetlost 21 hours ago [-]
> it's kinda abandonware at this point
That's sad. I'm a fan of rxi's work, including this one.
pstuart 11 hours ago [-]
It's MIT and these days handing it off to Claude to tart it up as needed should be viable.
It's not mine; just a project I've toyed with a few times in my search for GUI toolkits over the years. Issues and/or PRs can be filed on the github page though.
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)
afavour 23 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.
wefw3434 2 hours ago [-]
this is easy
question is how produce sms-message like text widget, with alligment like iphone
abtinf 23 hours ago [-]
The first thing I look for in any UI library is accessibility support. Makes it trivial to filter out toy projects.
RodgerTheGreat 23 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.
Dwedit 22 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.
jazzypants 23 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.
ironmagma 16 hours ago [-]
Not true... this is why they had to add aria- ...
jazzypants 15 hours ago [-]
Yes, exactly! Now, it's all built into the platform.
The first WAI-ARIA specification was published in 2014 [0]. HTML5 became an official W3C recommendation that same year [1]. It includes semantic elements like <nav> and <main> that have ARIA roles built in [2]. The Wikipedia page for WAI-ARIA includes the "five rules of ARIA" where the first rule is "Don’t use ARIA if you can achieve the same semantics with a native HTML element or attribute" [3].
You almost always still need some extra ARIA attributes to be fully accessible, but it's much less extra work than most other platforms and it works (mostly) the same on every operating system (including phones). You don't have to build anything yourself-- you just have to know which attributes to use. Just ask any blind people you know whether they prefer using a website or a native app.
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.
OK, if "toy project" isn't the right word, then perhaps, "unethical" or "exclusionary" would be better words to use.
I judge software harshly that could be useful to folks with accessibility needs that don't try to address it (within bounds of their resources and capabilities, obviously lots of OSS just doesn't have the ability to deliver an accessible experience for tiny little throwaway apps). I definitely choose technologies to use based on whether they can be accessible with a little extra effort on my part. I'm not necessarily good at it, it's a complicated topic, but when I get bug reports about an accessibility issue I tend to drop everything else and try to fix it.
I guess a lot of folks consider games exclusively for folks without those accessibility needs, so maybe that's why something like Dear ImGui can live for years in thousands of projects without anyone complaining about accessibility. But, I wouldn't consider it for anything that isn't specifically about graphics and I don't think anyone else should either. (No one has to listen to me, but I think less of them.)
Intralexical 13 hours ago [-]
> I guess a lot of folks consider games exclusively for folks without those accessibility needs, so maybe that's why something like Dear ImGui can live for years in thousands of projects without anyone complaining about accessibility. But, I wouldn't consider it for anything that isn't specifically about graphics and I don't think anyone else should either. (No one has to listen to me, but I think less of them.)
Immediate mode UIs are mostly for debug menus, not even gameplay/graphics. It doesn't need to be accessible to anyone except for the developer(s) choosing the library and making the game. (If the developer has different needs, obviously they can choose another library, unlike users who must live with the developer's choice.) The fourth sentence in the linked ImGUI repository explains this intention very clearly.
You can spend all this energy imagining malice and thinking less of others, but doing so does not add merit to your critique. Nor does it advance the cause of software accessibility.
SwellJoe 5 hours ago [-]
Literally none of the examples of large companies using it in the comment I replied to are game companies or using it for game debug menus.
You made up a guy and pretended I was yelling at them.
Intralexical 29 minutes ago [-]
> Literally none of the examples of large companies using it in the comment I replied to are game companies or using it for game debug menus.
Literally all of them are using it as part of non-user-facing debug tools for 3D graphics:
Meta as part of their VR/gaming division, Google in their VR division and 3D rendering engine, Ikea in a 3D material editor, and Intel in a 3D SDK.
And again, the intended use is immediately explained on the project repo no matter what the comment you were replying to said.
14u2c 14 hours ago [-]
You've cherry picked a very specific example that is designed to run in 3d engines. For anything rendering at standard OS api level level (the vast majority libs), accessibility is fine as evaluation criteria.
Intralexical 13 hours ago [-]
> You've cherry picked a very specific example that is designed to run in 3d engines.
This post is about a minimal immediate mode library made by a game dev, most suitable for debug menus.
It's unreasonable to treat it as a platform for soapboxing about "the vast majority libs" that are unrelated.
whizzter 23 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.
qsera 22 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!
anonymous908213 19 hours 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.
qsera 17 hours ago [-]
Get a load of this guy here. He thinks that humans beings cannot communicate if some computer programs does not talk in their language!
monocasa 23 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.
fwip 22 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.
monocasa 21 hours ago [-]
This library's default is greyscale anyway, so it's by default colorblind friendly.
Intralexical 13 hours ago [-]
Additionally the developer of this library is active in the indie game scene, so "twelfth member of the team" is hardly a relevant issue.
I find it so unfortunate how many of the criticisms raised here are mooted by simply glancing at the README.
There's an interesting conversation that could be had about the needs and limitations for debug UIs, and how to balance that with minimal code. (E.G. Would feeding this library's text-and-rectangles output into an accessible renderer be enough?) But blanket rejections and reflexive judgement aren't helpful.
functionmouse 13 hours ago [-]
Windows XP has better accessibility than anything since, by virtue of staying entirely out of the way of accessibility tools. Time to downgrade!
ricardobeat 16 hours ago [-]
Is there any game engine out there with good accessibility support for their UI?
nkrisc 16 hours ago [-]
I can’t say how it compares to others, but Godot added screen reader support in 4.5 a year or so ago.
jdmoreira 22 hours ago [-]
What? On a micro immediate mode UI?
Really insane comment TBH
dwb 21 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.
spwa4 23 hours ago [-]
Then just save yourself some time. Immediate mode and accessibility are mutually exclusive.
SeasonalEnnui 20 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).
Intralexical 13 hours ago [-]
> Any project that uses Dear Imgui for end-user applications has already made a bad design choice.
Note that any project using Dear ImGui will presumably have read the README for it, the second paragraph of which starts:
> Dear ImGui is designed to enable fast iterations and to empower programmers to create content creation tools and visualization / debug tools (as opposed to UI for the average end-user).
einpoklum 16 hours ago [-]
It's supposed to be a _tiny_ library. Naturally its capabilities will tend towards being minimal. I don't expect decent RTL language support, for example, although it's quite important if those are the languages where you live.
As for linking to something written in Rust with bindings etc. - that is the opposite of tiny when you consider the dependencies, and it would not be portable to weaker or older systems.
OvervCW 22 hours ago [-]
What is the advantage of this compared to Dear Imgui?
ranger_danger 22 hours ago [-]
it's lighter weight and written in C
hparadiz 16 hours ago [-]
I need something like this but with a few more bells and whistles.
amelius 15 hours ago [-]
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).
hparadiz 15 hours ago [-]
I know exactly what I need. I just built a task manager in C with GTK+. It uses the theming built into GTK to allow users to change themes while the program is running but it's too memory heavy for my taste. I also have a background in web dev and understand how to build for accessibility. Currently the memory allocated for every single process on my computer is <3 MB but the interface displaying that information uses almost 55MB total when rendering. I need the ability to set fonts, colors, and sizes and the ability draw text as desktop manager understandable standard copy/pastable text. I want the font rendering to support basic anti aliasing. The API also needs to expose draw surfaces for me to draw OpenGL/Vulkan as needed. It needs to support both X and Waylandisms for window decorations. I specifically need the API to support animated icons for window decorations as that is currently unsupported by anyone at all in this space. https://github.com/hparadiz/evemon
You're right though I'm already thinking of scaling and hidpi as another thing I need.
3 hours ago [-]
em-bee 18 hours ago [-]
anyone working on bindings to other languages? (go, python, ruby, etc)
HumblyTossed 18 hours ago [-]
I was just thinking this would be great with go. If it would work.
synergy20 23 hours ago [-]
how is this different from lvgl? is this immediate mode or retained mode?
flohofwoe 20 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.
peter_d_sherman 1 days 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"
einpoklum 16 hours ago [-]
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?
b3orn 16 hours ago [-]
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.
ur-whale 23 hours ago [-]
Nice, except the hard part seems to be missing: interfacing with an actual window system (X11, TUI, WIN32, whatever ...)
exDM69 23 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.
flohofwoe 20 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.
pkolchanov 6 hours ago [-]
I've worked on a minimal application layer (Cocoa, X11, win32) that you might find interesting. It includes a microui example.
In demo/ someone can "steal" the renderer part which, being based on SDL, is to some extent cross-platform.
Littice 1 days 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.
flohofwoe 20 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);
...how r_draw_text() is implemented is then entirely up to you.
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
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
- constant repainting (while literally nothing changes) -> constant CPU load
- some libs can skip repaints but have no concept of damage area
- bad handling of high-dpi (which also can change dynamically)
- constant repainting behaves even worse on laptops which announce 180 Hz refresh interval, which means that it drains the battery 3 times faster than 60 Hz
This doesn't explain a 100% CPU usage, especially not for such a simple demo. The entire per-frame load should only be a tiny fraction of a frame duration.
https://imgur.com/uy78t52
More details:
The demo is using half-resolution on high-dpi displays (currently that's sokol-app's default setting, but not sure if that still makes sense in this day and age tbh), this half resolution amplifies all sorts of text rendering issues, and it gets especially bad when there's a fractional system-dpi-scale like 125% or 150%.
PS: another problem (maybe the main problem, even if everything else is correct) is that the demo's pre-baked font atlas texture isn't all that great since it has 'anti-aliasing' baked into the glyph pixels, and the font atlas texture has a very low resolution (glyph height is 10 pixels, which would be ok for a 'crisp' hand-drawn bitmap font, but not when the font atlas has been created from a regular TTF font, which this one seems to be).
Does this Dear ImGui demo look better on your setup? This is using the native display DPI and uses a TTF font instead of a bitmap font:
https://floooh.github.io/sokol-html5/imgui-highdpi-sapp.html
I use pygtk and dont have to fiddle with lower level stuff
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 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.
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.
That's sad. I'm a fan of rxi's work, including this one.
Cosmopolitan Libc has since integrated the bits to make OpenGL work in cross-platform binaries and it's awesome.
[0] https://libagar.org/
https://libagar.org/screenshots/agar171.png
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
question is how produce sms-message like text widget, with alligment like iphone
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.
The first WAI-ARIA specification was published in 2014 [0]. HTML5 became an official W3C recommendation that same year [1]. It includes semantic elements like <nav> and <main> that have ARIA roles built in [2]. The Wikipedia page for WAI-ARIA includes the "five rules of ARIA" where the first rule is "Don’t use ARIA if you can achieve the same semantics with a native HTML element or attribute" [3].
You almost always still need some extra ARIA attributes to be fully accessible, but it's much less extra work than most other platforms and it works (mostly) the same on every operating system (including phones). You don't have to build anything yourself-- you just have to know which attributes to use. Just ask any blind people you know whether they prefer using a website or a native app.
[0] https://www.w3.org/TR/2014/REC-wai-aria-20140320/Overview.ht...
[1] https://www.w3.org/news/2014/html5-is-a-w3c-recommendation/
[2] https://www.w3.org/WAI/WCAG22/Techniques/html/H101
[3] https://en.wikipedia.org/wiki/WAI-ARIA
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 judge software harshly that could be useful to folks with accessibility needs that don't try to address it (within bounds of their resources and capabilities, obviously lots of OSS just doesn't have the ability to deliver an accessible experience for tiny little throwaway apps). I definitely choose technologies to use based on whether they can be accessible with a little extra effort on my part. I'm not necessarily good at it, it's a complicated topic, but when I get bug reports about an accessibility issue I tend to drop everything else and try to fix it.
I guess a lot of folks consider games exclusively for folks without those accessibility needs, so maybe that's why something like Dear ImGui can live for years in thousands of projects without anyone complaining about accessibility. But, I wouldn't consider it for anything that isn't specifically about graphics and I don't think anyone else should either. (No one has to listen to me, but I think less of them.)
Immediate mode UIs are mostly for debug menus, not even gameplay/graphics. It doesn't need to be accessible to anyone except for the developer(s) choosing the library and making the game. (If the developer has different needs, obviously they can choose another library, unlike users who must live with the developer's choice.) The fourth sentence in the linked ImGUI repository explains this intention very clearly.
You can spend all this energy imagining malice and thinking less of others, but doing so does not add merit to your critique. Nor does it advance the cause of software accessibility.
You made up a guy and pretended I was yelling at them.
Literally all of them are using it as part of non-user-facing debug tools for 3D graphics:
https://github.com/ocornut/imgui/wiki/Software-using-dear-im...
Meta as part of their VR/gaming division, Google in their VR division and 3D rendering engine, Ikea in a 3D material editor, and Intel in a 3D SDK.
And again, the intended use is immediately explained on the project repo no matter what the comment you were replying to said.
This post is about a minimal immediate mode library made by a game dev, most suitable for debug menus.
It's unreasonable to treat it as a platform for soapboxing about "the vast majority libs" that are unrelated.
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!
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.
Like a debug UI in a game engine, or in an embedded device that doesn't even have input for a13y.
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.
I find it so unfortunate how many of the criticisms raised here are mooted by simply glancing at the README.
There's an interesting conversation that could be had about the needs and limitations for debug UIs, and how to balance that with minimal code. (E.G. Would feeding this library's text-and-rectangles output into an accessible renderer be enough?) But blanket rejections and reflexive judgement aren't helpful.
Really insane comment TBH
Note that any project using Dear ImGui will presumably have read the README for it, the second paragraph of which starts:
> Dear ImGui is designed to enable fast iterations and to empower programmers to create content creation tools and visualization / debug tools (as opposed to UI for the average end-user).
As for linking to something written in Rust with bindings etc. - that is the opposite of tiny when you consider the dependencies, and it would not be portable to weaker or older systems.
You're right though I'm already thinking of scaling and hidpi as another thing I need.
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.
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"
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.
https://github.com/pkolchanov/brr
But the way how text rendering is delegated to the user is quite flexible, microui basically calls these three user-provided functions:
...how r_draw_text() is implemented is then entirely up to you.