Live data from Hacker News

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

github.com

51–60 of 103 posts

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

#51

Earlier quoted context omitted.

License issues aside the typical use case is that you want to integrate the UI with an existing 3D renderer (e.g. you have a 3D engine, and want an UI overlay for tooling and debugging). 'Bring your own renderer' UI frameworks like Nuklear or Dear ImGui are perfect for this use case. With 'traditional' UI frameworks like Qt, WPF, GTK... this is a massive PITA and even if it's possible would add an incredible amount o…

will immediate mode keep the cpu active thus not power saving friendly?

Immediate mode UIs tend to be more practical in applications where you're updating the entire screen every frame anyway. If your application is going to be mostly static anyway, a retained mode UI will probably better serve your needs, and also be easier on power.

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

#52

I tend to use ImGui for testbed projects. It's flexible and quick to get up and running. I only have two minor complaints about it. 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 suspect (1) is just because Dear ImGui is BYO graphics backend, so it doing lots of clever texture management stuff for lots of images would increase the surface area of that integration which would make it harder to use for most folks.

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

#53
post #40
post #31

Earlier quoted context omitted.

rapid development/prototyping

But it's faster to use a QList than having to do the same in C (repeat for all the non GUI classes that Qt brings in).

Not faster to integrate it into a build system or compile it though.

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

#54

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.

One of their demos already has a software rasterizer. I've used it to draw directly to a frame buffer for a custom OS that didn't support accelerated graphics. It's in the demo directory under x11_rawfb. I made some tweaks to that (getting rid of all X11 stuff) and wrote my own fb/tty/mouse/keyboard driver and got it working great without any graphics API layer between it and the pixels that get drawn directly to video memory and the screen.

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

#55

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

It does. I've done it, starting with their x11_rawfb demo. It's pretty nice, but I've personally switched to using LVGL (https://github.com/lvgl/lvgl) for the OS I work on, as I find it a better fit for the purpose. I do still have a soft spot for Nuklear though, and depending on what you're trying to do with your OS, could also be a good fit. Really not hard to get it going if you don't mind implementing your own keyboard/mouse driver layer.

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

#56

Earlier quoted context omitted.

License issues aside the typical use case is that you want to integrate the UI with an existing 3D renderer (e.g. you have a 3D engine, and want an UI overlay for tooling and debugging). 'Bring your own renderer' UI frameworks like Nuklear or Dear ImGui are perfect for this use case. With 'traditional' UI frameworks like Qt, WPF, GTK... this is a massive PITA and even if it's possible would add an incredible amount o…

will immediate mode keep the cpu active thus not power saving friendly?

You can pause your main loop when there is no input or animations that would require a redraw. That saves a lot of CPU when the app is idle. You need to run on mouse moves if you want hover effects though.

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

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

See also the FOX Toolkit, which is still just about alive.

https://www.fox-toolkit.org/

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

#59

Nuklear is great. I’ve spent countless hours hacking around with it. I’ve also built a customized version for classic Macintosh systems (down to System 2.0 or so) and built some simple Macintosh software for it. I put it on GitHub here: https://github.com/CamHenlin/nuklear-quickdraw

Now that's just awesome - I'll definitely have to play with this! What's the performance like on low-powered CPUs?

I went through great lengths to get it somewhat usable on slow CPUs. This is really where I spent the majority of my time. Check out my blog post introducing nuklear QuickDraw here https://henlin.net/2021/12/21/Introducing-Nuklear-for-Macint... where I have it running the nuklear calculator demo on an 8mhz Macintosh emulator in your web browser. The less you try to do on slow systems the better it is.

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

#60
Ping me when it can WebKit

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.

Post reply on HN