Live data from Hacker News

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

github.com

11–20 of 91 posts

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

#11
post #4

Nice, except the hard part seems to be missing: interfacing with an actual window system (X11, TUI, WIN32, whatever ...)

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.

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

#12
post #5

The first thing I look for in any UI library is accessibility support. Makes it trivial to filter out toy projects.

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

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

#14
post #5

The first thing I look for in any UI library is accessibility support. Makes it trivial to filter out toy projects.

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

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.

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

#15
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.

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

#17

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 is…

[flagged]

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

#18
post #5

The first thing I look for in any UI library is accessibility support. Makes it trivial to filter out toy projects.

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

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.

Post reply on HN