Live data from Hacker News

Nuklear – A single-header ANSI C immediate mode cross-platform GUI library

github.com

11–20 of 103 posts

Re: Nuklear – A single-header ANSI C immediate mode cross-platform GUI library

#11
post #5

Interesting, this seems more resource efficient than even fltk, which is the lightest usable cross-platform GUI library. And it's pure C unlike fltk. It's great to see such projects in an era of unabashed resource consumption.

The price for the 'lightest' general UI toolkit probably goes to microui: 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: https://floooh.github.io/sokol-html5/sgl-microui-sapp.html

Your demos are really cool!

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

Re: Nuklear – A single-header ANSI C immediate mode cross-platform GUI library

#13
post #5

Interesting, this seems more resource efficient than even fltk, which is the lightest usable cross-platform GUI library. And it's pure C unlike fltk. It's great to see such projects in an era of unabashed resource consumption.

The price for the 'lightest' general UI toolkit probably goes to microui: 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: https://floooh.github.io/sokol-html5/sgl-microui-sapp.html

Impressive. This is suckless-grade minimalism.

Re: Nuklear – A single-header ANSI C immediate mode cross-platform GUI library

#15
post #9

I've been using nanogui[0] to fit the bill for personal uses. 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…

Would redbean work for your purpose? It's very lightweight and fun to work with, though not suited for everything.

https://redbean.dev

Re: Nuklear – A single-header ANSI C immediate mode cross-platform GUI library

#16
post #10

Earlier quoted context omitted.

The price for the 'lightest' general UI toolkit probably goes to microui: 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: https://floooh.github.io/sokol-html5/sgl-microui-sapp.html

I love these kinds of UI frameworks except for one thing -- the text is always so poorly rendered. Not sure if it's just poor fonts or lack of good antialiasing, but compared to how a browser or native windowing system renders text, immediate mode GUIs are practically unbearable and make me want to close them after short usage. Maybe because I use a high-DPI screen (Macbook Air), not sure, but it feels like taking a…

The default fonts are just plain awful. It's trivial to drop in a better font and make it indistinguishable from native.

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?

Re: Nuklear – A single-header ANSI C immediate mode cross-platform GUI library

#17

Does this support writing to a linear frame buffer? Would be interesting to port to run on my OS if so.

Nuklear returns a bunch of vertices, vertex-indices and draw commands, so it plugs best into a 3D API (like GL, D3D, Metal, Vulkan...). To render into a frame buffer you'd need to implement a simple software rasterizer with texturing support.

Re: Nuklear – A single-header ANSI C immediate mode cross-platform GUI library

#18
post #10

Earlier quoted context omitted.

The price for the 'lightest' general UI toolkit probably goes to microui: 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: https://floooh.github.io/sokol-html5/sgl-microui-sapp.html

I love these kinds of UI frameworks except for one thing -- the text is always so poorly rendered. Not sure if it's just poor fonts or lack of good antialiasing, but compared to how a browser or native windowing system renders text, immediate mode GUIs are practically unbearable and make me want to close them after short usage. Maybe because I use a high-DPI screen (Macbook Air), not sure, but it feels like taking a…

I must mention that the WASM demos all render to a half resolution framebuffer when running on a high-dpi display, and the resulting aliasing and upscaling may introduce all sorts of artefacts (even as late as in the browser and window system).

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.

Re: Nuklear – A single-header ANSI C immediate mode cross-platform GUI library

#19
post #10

Earlier quoted context omitted.

I love these kinds of UI frameworks except for one thing -- the text is always so poorly rendered. Not sure if it's just poor fonts or lack of good antialiasing, but compared to how a browser or native windowing system renders text, immediate mode GUIs are practically unbearable and make me want to close them after short usage. Maybe because I use a high-DPI screen (Macbook Air), not sure, but it feels like taking a…

The default fonts are just plain awful. It's trivial to drop in a better font and make it indistinguishable from native. 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?

Font is one thing.

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.

Re: Nuklear – A single-header ANSI C immediate mode cross-platform GUI library

#20
post #9

I've been using nanogui[0] to fit the bill for personal uses. 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…

Would redbean work for your purpose? It's very lightweight and fun to work with, though not suited for everything. https://redbean.dev

Not exaclty -- it looks like it's pretty overkill for my needs

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.

[0] https://docs.websocketpp.org/

[1] https://github.com/uNetworking/uWebSockets

Post reply on HN