Nuklear – A single-header ANSI C immediate mode cross-platform GUI library
github.com
github.com
https://floooh.github.io/sokol-html5/nuklear-sapp.html
The big difference to Dear ImGui is that Nuklear has a C API and is also implemented in C - and apparently it has more skinning/themeing options, which I haven't tinkered with yet.
TBH, for tools I prefer cimgui (a C wrapper around Dear ImGui), my impression is that Nuklear has a 'purer' immediate-mode design at the cost of some convenience, while Dear ImGui has a more pragmatic design approach, but also has less friction for writing UI code. I haven't needed skinning options so far though, that might be the actual USP of Nuklear.
It all might also just be personal bias, because I used Dear ImGui before Nuklear :)
For shits'n'giggles, here's both UI systems in the same application:
https://floooh.github.io/sokol-html5/nuklear-sapp-ui.html
(the menu bar and all windows that open from it is Dear ImGui, the rest is Nuklear).
The check-box being an empty square when it's checked, and a filled square when it's unchecked is an unpopular design decision.
Then copy and paste took over.
The best example and how I learnt about this is the mute toggle on iPhones and the lock toggle on the old iPods.
When you turned the switch ‘on’ it turned the sound/buttons ‘off’. The signify this special kind of ‘inverted’ switch, they put the orange colour on there. [1]
This is a rare use case but it does exist. And definitely shouldn’t be the default in the UI library
[1] https://d3nevzfk7ii3be.cloudfront.net/igi/mmIJOyYlvjSvCBrH.m...
> 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).
Not sure about that, maybe javascript with svg would be easier to write such an app in.
Unofficial C API - https://github.com/cimgui/cimgui Official binding gen - https://github.com/dearimgui/dear_bindings
To be honest though, I'm at the point where I'd really prefer an easy and lightweight library to setup a http and/or websocket server, and just make a ui in the browser. I've got a simple use case -- I'm just making a simple scene editor & debugging ui for a toy ray tracer.
I know there are a ton of different libraries out there for the task, but that just makes it hard to evaluate the quality of any given library. I haven't given any a shot, I've only gone so far as to look at them and ponder what the size of the user base is, and question if the project will go inactive in a couple years. Or if it's going to require me to pull in some other host of dependencies.
Recommendations from HNers welcome!
I'm looking for something more like websocketpp[0], or even just grpc without a requisite proxy. uWebsockets looks really promising, being header only, but in the fine print requires a runtime library. unfortunately, none of that ecosystem seems to use cmake, making integrating it that much more of a pain.
why use cpp for this, I'm sure some HNer will ask. the ray tracer itself is using cuda, that's why. I've also debated
- running it as a grpc server and having some proxy in a more web-accessible language
- creating python bindings and using python to make a websocket/http server for it
neither of those are out of the question, but they're not my first choices, because I'd like to keep the build & execution simple. introducing dependencies, especially other executables, is in conflict with that.
i don't need anything particularly scalable -- a threaded implementation, or one using select() would be fine, if not preferable.
Wouldn't that mean that the expiry date of your GUI is like: a few years or so?
Since web-stuff seems to change so constantly with breaking changes and revamps every few years being the norm.
Whereas a WIN32 app (or Unix or other) from 25 years ago probably still runs fine? I can't imagine the same for any web-app that was written for Netscape and now has to run in a modern browser.
you see a lot of churn in the web ui world because browsers implement new features that new libraries take advantage of. it seems to be stabilizing a bit around react. the developers in the space do tend to reinvent the wheel more.
it's not that big of a deal to me though, because it's a pet project, not a professional product. if i want to show it off to non-technical friends/family, it's a lot easier for me to point them to a webpage than it is to have them install some binary I produce.
having a native gui isn't precluded going this route either, I'd just have a native gui connect via socket rather than interact directly.
> Whereas a WIN32 app (or Unix or other) from 25 years ago probably still runs fine? I can't imagine the same for any web-app that was written for Netscape and now has to run in a modern browser.
Sure, but then I'd have to learn all of the platform specific apis, or go with something like nuklear or nanogui (like i'm doing now). which is fine, sort of. it's not really the development I want to be doing, and it's got a frustrating workflow.
Just due to my background, having started my career in webdev, i feel more comfortable doing ui work in a browser than i do fussing with native or opengl based uis.
Also because of design language evolution (whether this is “fashion” or “advances in usability research” is a debate I’ll sidestep here); the old stuff still works fine, it just isn’t current style; if all you care about is “UI that works” and not “UI that looks and feels current”, web isn’t a bad target.
Nuklear: A cross-platform GUI library in C - https://news.ycombinator.com/item?id=26212787 - Feb 2021 (142 comments)
Nuklear: A single-header ANSI C GUI library - https://news.ycombinator.com/item?id=16347216 - Feb 2018 (176 comments)
Nuklear: A small ANSI C GUI toolkit - https://news.ycombinator.com/item?id=11522452 - April 2016 (92 comments)
Of course, I forgot to add a frame limit so it ate up a full CPU core at first, but after fixing that, the usage was basically zero.
It's great to see such projects in an era of unabashed resource consumption.
https://github.com/rxi/microui
Just around 1100 lines of C code.
You need to bring your own renderer, but that's the same for Nuklear or Dear ImGui.
I wrote a WASM wrapper for the microui demo too:
Possibly a licensing issue as to why they don't include better ones by default as you have to bake it in? or they want to make the binary as tiny as possible by not using a bigger font file?
The hard part is text layout which is a very very complicated affair, especially if you want to support different languages and/or writing systems.
I've configured the canvas upscaling to use point filtering because that looks nicer for Dear ImGui's and Nuklear's default pixel fonts (otherwise the text look slightly blurry after the upscaling), but the point filtering doesn't look exactly great for microui's default font.
Using a proper TTF font rendered in native resolution on a HighDPI display will look a lot better. But proper 'non-native' text rendering is a surprisingly tricky thing to do right.
A nice font renderer is orders of magnitude more code, e.g., harfbuzz 25,000 lines of code with or FreeType with 245,000 lines of code. Many projects do not want that kind of bloat.
I'd guess some of these little ones allows using your own bmp font, so render a font you like, and use the rendered glyphs.
It isn't bloat if it's desired functionality. Not every project is optimized to run in an embedded environment, nor does it need to be.
And if you in particular want it, fork them and merge them.
https://floooh.github.io/sokol-html5/
Interestingly the imgui and nuclear both work on mobile while the microui demo doesn't appear to handle any input. Imgui works surprisingly well (although everything is a bit small for touch).
It also uses heuristics to find the right window that can lead to issues. Not a common problem, but one I unfortunately ran into :(
* Raylib - A single header file game engine https://www.raylib.com/ * Miniaudio - A single header file audio library https://miniaud.io/
Both (actually, not just three systems) cross-platform.
For their design and cross-platform support they make for great bases for Go libraries, unlike most C code out there.
Immediate mode GUIs are usually pretty nice from a developer point of view, but many of them are lacking many things like accessibility and text selection. Maybe good for 3D modelers, video editors, etc., but not for more general purpose apps.
Harping on immediate mode GUIs doesn't help. I don't think anyone is against making IM GUIs more accessible.
The predominant immediate mode library in Go, Gio, has been slowly working on support for various ecosystems. I believe it supports Android to some extent already.
For accessibility I think that's sadly a part that people in general don't seem to care a lot. And while some of the big libraries do a lot for you there, it also depends a lot on how it really is used. The trend to Electron and others also isn't really helping there.
To be fair though, I am happy about the trends that this topic is actually something people even are aware of. Five, ten, fifteen years ago this was very different. I remember a time when using HTML over Flash for accessibility reasons was considered a non-argument. Now you see that topic brought up "a lot".
As for small and simple libraries... it's great when the subject matter is also small and simple. UI is not, though.
It supports almost all of the popular back-ends across platforms. A library as complex as PortAudio in a (largish) header.
1. It would be nice to have some built in image handling functions, i.e. to be able to allocate and draw images on the screen.
2. Skinning is currently rather limited. (I know this has been a long requested feature).
Other than those minor gripes, I like it a lot.
I think this would actually be fairly tricky to handle inside Dear ImGui, because the image object must be in a format that's understood by the rendering backend. The way ImGui handles image rendering via an opaque ImTextureID handle which is passed through to the renderer backend is actually quite elegant IMHO.
I've never found this to be problematic. Long before ImGui even gets involved I've already got stb.h and a spinning textured cube.
Anyway usually the consensus is that it's worth to save human time increasing compilation time. Otherwise nobody would use Rust instead of C
...and then there's also the convenience of writing immediate mode UI code. Personally, I would never want to go back to event-/callback-/signal-driven UIs.
It's geared more for embedded, but you can use an sdl back end for desktop (which might kill your light weight requirement depending on your strictness level). I wrote my own tty/framebuffer driver for it and use it directly on the frame buffer (not Linux) but it's pretty nice to work with. But if you need metal/openGL/Vulcan/directX and hardware acceleration, it's probably not what you're after.
I'm hoping the wxWidgets creators will rewrite their library in Rust or at the very least create bindings for it.
Just why. C17 exist.
Why is is that some developers stick with C89, whilst in the C++ community, unless you work for some really backwards company, you adopt the latest standard before it's even officially nailed down?
C89 needs to die. Stop supporting it.
> Reviewing changes to src/* and nuklear.h:
> Ensure C89 compatibility
Feel free to fork at your convenience!
Would have been more accurate.
EDIT: this was flippant of me, but I was trying to make a real point.
I'm simply too used, as a front-end dev, to the flexibility I get from CSS and HTML and SVG and React, and React-Three-Fibre for fancy stuff. Put it in Electron and boom.
Yes, it's a horrible, horrible mess. Yes, it's ungainly. Yes, it's twenty layers of abstraction.
But Electron apps have come an enormous way. My favourite apps are now all Electron. While non-Electron apps make a strong start, they simply cannot keep up with the innovation made possible by here-you-go-ing the last 30 years of web progress.
Yeah, I know that's not the use case for something like this. Opposite! Opposite! But you know what? For most medium-sized 2022 front-end workloads, widgeting is a thoroughly solved problem.
By 2030, most apps will include an entire web browser, just as insurance for future market-competitive growth rate.
This is why adopting MAUI, Blazor, etc, is folly, and even this kit -- aside from it obvious hacker-cool minimalist street cred -- is the sort of 'meme dependency' (rhymes with meme stock) that HN adores despite the fact that it will see almost no non-toy use cases.
Get yourself a web browser. HTML is the VT220 of 2030.