commented:
UI toolkits are one of those things that are easy to throw together
but very hard to make good. There's a million little details that
users will expect of a UI widget. Some of them (line-editing
shortcuts, typing in a popup menu to jump to an option) will just
annoy power users if they're missing, others (integrating with screen
readers and non-Latin input methods) are absolutely essential for some
users, even though you probably never use them.
I'm don't like to discourage these sorts of toy projects - they're
super cool! But I do always worry that someone will see something like
this, find it superficially does everything they need, and end up
shipping a substantially worse product than they'd have had if they
used a more mature library. I'm not sure how you solve this.

  commented:
Maybe there's a way to further break down the problem space.
I'd be curious to see a UI toolkit that's split into two parts: a
compiled-language runtime, with widgets in an embeddable scripting
language. The intent would be to lower the barrier to contributions
for those "million little details." Let's say a dev has already
started using the toolkit, and they're already annoyed that the
dropdown widget isn't keyboard friendly. If the whole toolkit was in
C++ or Rust, they might not feel empowered to improve it; yeah, I know
the UI kind of sucks, but I can live with it, and fixing it sucks
more. Whereas if the widget logic was in Wren, they might just go in
and hack that one feature into their copy of the dropdown code. (And
hopefully, upstream it at some point.)
If this two-part split reminds you of Electron and JS, there are some
similarities. But I'm not advocating for Electron here. Whereas
Electron wants your whole app to be a web app, I'm saying you could
have a lightweight runtime with only the widgets implemented in a
lightweight scripting language—and your app would be in whatever
language you have bindings for.

  commented:
Nakst's UI library tutorial continues on in Luigi. The library is
somewhat similar to the Win32 API (with a message procedure for each
"class") and uses lots of message passing. This is quite different
from GTK or Motif which might make it interesting for people who want
a C library "in the spirit of" Win32 but without the horrible
Hungarian notation.
.