Nuklear: A small ANSI C GUI toolkit

by ingve • 10 years ago

279 92 10 years ago

This looks quite nice. But they did fib a bit about no dependencies. It is apparently built on top of GLFW3 which is a nice, small C library that gives you a native window and input handling.

i336_• 10 years ago

There's also a pure X11 version, which only pulls in what X requires:

  $ make
  gcc main.c -std=c89 -pedantic -O2 -D_POSIX_C_SOURCE=200809L -o bin/zahnrad -lX11 -lm
  $ ldd bin/zahnrad 
           linux-vdso.so.1 (0x00007ffe32df9000)
           libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f8468746000)
           libm.so.6 => /usr/lib/libm.so.6 (0x00007f8468441000)
           libc.so.6 => /usr/lib/libc.so.6 (0x00007f84680a0000)
           libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f8467e7d000)
           libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f8467c79000)
           /lib64/ld-linux-x86-64.so.2 (0x00007f8468a88000)
           libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f8467a75000)
           libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f846786f000)

generic_user2• 10 years ago

Cross platform is a key feature. Thats why glfw is so nice. Unless you want to write the grungy windows bits for all your platforms I don't see any problem with useing glfw. Its a solid library.

digi_owl• 10 years ago

Odd seeing that in this day and age. I though everyone was hot and bothered about Wayland...

osmala• 10 years ago

Nope, it isn't. GLFW3 is in example use of library. There is not a single instance of string "glf" in actual library. The library claims that it is agnostic to what actual low level layer you provide to it so you can use it with what ever you choose as render target and what ever you choose as input source. Its user of library's task to provide those two and link to GUI.

wtbob• 10 years ago

Really pretty. Given how small it is, I wonder how difficult porting it to other languages would be; it might make a decent little reference spec for lightweight GUIs.

richard_todd5• 10 years ago

It looks cool, though the claim about having no platform dependent code must be false... either they have it or they depend on someone who does. Since it's all in one file and I'm on an iPad right now, I didn't try to discern which case it is.

What is the appeal of the implementation hiding in the header file? Is it a 'thing' nowadays? It makes every file that includes it read all 15k lines, and makes you put a special #define in one of your source files, just to avoid having a C file. That doesn't feel like a good trade-off to me. If I used this code in a project, I'd build a static library out of it first thing, and go about my business.

nightcracker• 10 years ago

does not have any dependencies, a default renderbackend or OS window and input handling but instead provides a very modular library approach by using simple input state for input and draw commands describing primitive shapes as output.

It seems that you're expected to provide the layer between the OS and nuklear. They probably have some default implementation for demo's and stuff.

richard_todd5• 10 years ago

Ah, I read that three times on the site but it didn't sink in until I saw your comment. I guess with a title like "GUI toolkit" my expectations were set incorrectly. Thanks for that!

So, you glue it to the OS yourself. That's... well actually I guess if someone marries it to SDL it could be very useful.

taneq• 10 years ago

Interesting. So to answer the other poster who complained about the use of pixels rather than "display units", your lower 'glue layer' could accept dp in the input and scale the output to provide density-independent behaviour?

flohofwoe5• 10 years ago

Sean Barrett (of stb headers fame) has written about the reasons for header-only libraries here:

https://github.com/nothings/stb/blob/master/docs/stb_howto.t...

If compile-time is a concern (it isn't in my experience, at least if the rest of the project is C++ code), you can still wrap the library-header into your own header and put include-guards around it :)

PS: also see here: https://github.com/nothings/stb#why-single-file-headers

Avshalom2• 10 years ago

Because apparently archived files are just too much for Windows devs?

acqq2• 10 years ago

The "library" doesn't have to be in headers to be statically linked, the stated arguments to push everything in header are flawed.

b6• 10 years ago

The author of Nuklear mentions it in the readme, but in case people don't spot it, there's another cool project in this family, imgui: https://github.com/ocornut/imgui

stonogo• 10 years ago

Shame that you specify pixels in the function calls themselves. If it were really abstracted, it would have an arbitrary 'size unit' which the glue code could translate on the backend.

In a world where one user has a 1366x768 screen and her neighbor has a 4k display, we need to move past interface code specifying pixel sizes up front, both on the web and off.

vurtun3• 10 years ago

There are two different versions. The first one uses pixel measurements like you said the other one uses a fractions of the window. If it is something requested then it is something that can be changed quite easily either by me if the feature is requested or the user since it only requires modifying one function. Furthermore for input you only provide your input data the library does not control it and the output can be scaled if required.

CamperBob24• 10 years ago

Do you want Qt? Because this is how you end up with Qt.

(I'm mostly kidding but in my experience, the sorts of apps that you build with this sort of library invariably end up dealing with pixels anyway. There's no religious reason why resolution-independent scaling code has to live in the UI primitive library, especially since it probably can't be confined there.)

unexistance• 10 years ago

I always have an idea in my mind that we should scale / show the interface based on font-size, adjusting borders / button accordingly

p/s: obviously I have NO idea how easy / complex this would be, just an idea given that sometimes text contained in an element bleeds / overflows / outright missing

ktRolster5• 10 years ago

Problem is, we still have jpgs. As long as we have raster images (instead of vector images), we'll be laying some things out based on pixels.

And as long as we have photographs, we're going to have raster images, for the foreseeable future.

m_eiman• 10 years ago

That takes you towards HTML- or XAML-style UI definitions. I'm doing something like this in my (experimental) layout lib for embedded devices. I've written a bit about it: https://www.eiman.tv/blog/posts/liblayout/index.html

jws• 10 years ago

I find that pixels are appropriate at both the "small code" end and the "perfect display" end of user interface rendering. In between the "I have lots of CPU but I can't afford the mental time to get this perfect" is served well by abstract units.

The problem that hits abstract units is that for features which are small, you never really know how big they will be. It's easy to end up with elements which should look similar but some are three pixels wide and some are four, or the spacing is a little ragged from the rounding. Some kits avoid this by just antialiasing everything. Then you try to draw a detailed graph or a musical score and some of your horizontal lines are sharp and crisp because they hit solidly inside a pixel, and some are a grey smear because they hit a crack.

This is probably a large reason why many graphs and charts you see on the web look like they were drawn by a child with a felt tip marker. A 3 pixel wide line is pretty forgiving about where it falls.

panic• 10 years ago

Graphics on a 1366x768 display end up looking like mush if they're not aligned to pixels. Once everything's higher-res this will be less of an issue, though.

aceperry• 10 years ago

I'm glad they didn't name it "nu-kew-lar."

dmytroi• 10 years ago

Would be awesome to combine it with something like https://bitbucket.org/rmitton/tigr which is a small and tidy window creation/input processing lib, because I find glfw and SDL too bulky for casual C/C++ programming.

vurtun3• 10 years ago

There is nothing really dependent on any of the provided demos. As long as you are able to provide an OS window, input and a way to either draw basic shapes or vertexes you are good to go.

ktRolster5• 10 years ago

nuklear.h is 20,000 lines long. Is the whole thing written in the header file?

mmozeiko2• 10 years ago

Yes! https://github.com/nothings/stb#why-single-file-headers

optforfon• 10 years ago

I'm confused by the reasoning... why can't you just statically link your distributed exe?

int_handler2• 10 years ago

So basically the main motivation for this is that Windows makes it difficult use shared C++ libraries?

ktRolster5• 10 years ago

When I look at GUI APIs, the first question I ask is, "How easy is it to get things where I want them on the screen/page?" Because that is the fundamental problem for any layout engine.

Keyframe• 10 years ago

That's an easy question to ask if you know the screen aspect and resolution. What if you don't know either or both? The question suddenly shifts to "Where do I want things on screens?" and suddenly it's not about library anymore.

ktRolster5• 10 years ago

That's an easy question to ask if you know the screen aspect and resolution.

Surprisingly, in a lot of GUI libraries, it's not an easy thing.

joeld424• 10 years ago

Nice job! This looks great.

atemerev• 10 years ago

An alternative (in C++, but with C API maintained):

https://github.com/ocornut/imgui

aoloe• 10 years ago

the difference being that, when i saw nuklear's README, i just wanted to learn enough C to be able to use it... with imgui the first reaction was (the first time i saw it), that i won't be able to use it for software targeting non-geeks. (and i really would like to have a good lightweight UI framework for C++!)

it might be just the screenshots, i've not tried any of both, but comparing the two README files, i cannot say that they are real alternatives.

even if -- very likely -- both are very good toolkits!

chmike2• 10 years ago

I do have font size issue with nuklear and imgui. The font size used in the nuklear extended example make it look fuzzy, especialy if I change the scale.

I tested the imGui and changing the code allowed to select a bigger font. I wished it was possible to change the widget look and feel because it looks minimalist.

netgusto• 10 years ago

Any hint on how to compile any of the demos on OSX ?

vurtun3• 10 years ago

As far as I know glfw, sdl and allegro work for OSX as well. But if that is not the case I still have demo code for Mac, iOS and tvOS. The problem is I don't have any of these platforms and the demos are from an old version. So if somebody is found to take over the porting I can release it again.

fdb2• 10 years ago

I've got it running on OS X with some modifications:

- In the Makefile, use

  LIBS = -lglfw3 -framework OpenGL -lm -lGLEW

- In the main.c file of the project, change headers to use <OpenGL/gl.h> and <OpenGL/glu.h>

- In the shader code, change "#version 300 es" to "#version 400" for both the vertex and fragment shader.

I'll try to make a PR with conditionals if I can find the time today.

devy• 10 years ago

  $ brew install homebrew/versions/glfw3
  $ cd examples; make all

Should do the trick.

starbugs• 10 years ago

I forked the repo and created an Xcode project to play around with the GLFW demo: https://github.com/starbugs/nuklear

You need to install glfw3 and glew via brew:

$ brew install glew

$ brew tap homebrew/versions

$ brew install --build-bottle --static glfw3

buserror• 10 years ago

Looks like a great piece of tool! Very often you want to throw something together and the development grind to a complete halt because having to fiddle with the UI integration. Problem solved!

X11 example doesn't seem to run here, on my debian sid+nvidia blobs drivers. The GL* do work tho, abeit with un unreadable font (I'm on a 32" 3180x2160 screen)

X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 70 (X_PolyFillRectangle) Serial number of failed request: 29 Current serial number in output stream: 102

chmike2• 10 years ago

Unfortunately, the font looks very fuzzy (out of focus) when running the extended example. Is there a way to fix that ?

paulofalcao• 10 years ago

Another cool one https://github.com/fruxo/turbobadger

swah• 10 years ago

A really enjoyable talk on the topic by Casey Muratori (http://handmadehero.org): http://mollyrocket.com/861

chris_wot• 10 years ago

In case anyone wants to see a C++ framework that evolved over time and then was inextricably tangled up in the one application that really used it, check out OpenOffice/LibreOffice's Visual Component Library (VCL).

A demo program can be found here:

https://cgit.freedesktop.org/libreoffice/core/tree/vcl/workb...

A more complex, feature complete demo can be found here:

https://cgit.freedesktop.org/libreoffice/core/tree/vcl/workb...

ausjke3• 10 years ago

the SDL demo has lots of dependencies obviously, so it's really not something self-contained. I'm always excited any neat GUI for C, but this one seems like just a layer on top of existing GUI libraries, what's special about it? Please shed some light.

If it's really light-weight and self-contained it will be very useful for some embedded systems with a screen.

  $ldd bin/demo 
	linux-vdso.so.1 =>  (0x00007fff46f49000)
	libSDL2-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 (0x00007f3587140000)
	libGL.so.1 => /usr/lib/fglrx/libGL.so.1 (0x00007f3586f5e000)
	libGLEW.so.1.6 => /usr/lib/x86_64-linux-gnu/libGLEW.so.1.6 (0x00007f3586cf2000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3586934000)
	libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f3586647000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f358634a000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3586146000)
	libpulse-simple.so.0 => /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 (0x00007f3585f42000)
	libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f3585cf9000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f35859c4000)
	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f35857b3000)
	libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f35855a8000)
	libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f35853a5000)
	libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f3585195000)
	libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f3584f8c000)
	libXss.so.1 => /usr/lib/x86_64-linux-gnu/libXss.so.1 (0x00007f3584d88000)
	libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f3584b83000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3584965000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f358475d000)
	libatiuki.so.1 => /usr/lib/fglrx/libatiuki.so.1 (0x00007f3584640000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f3587469000)
	libpulsecommon-1.1.so => /usr/lib/x86_64-linux-gnu/libpulsecommon-1.1.so (0x00007f35843e1000)
	libjson.so.0 => /usr/lib/x86_64-linux-gnu/libjson.so.0 (0x00007f35841d9000)
	libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f3583f94000)
	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f3583d76000)
	libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f3583b6c000)
	libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f3583965000)
	libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f358375c000)
	libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f35834f5000)
	libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f35832ef000)
	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f35830ec000)
	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f3582ee5000)
	libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f3582ccb000)
	libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007f3582a81000)
	libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f35825b1000)
	libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f3582385000)
	libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007f358217e000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f3581f61000)

fdb2• 10 years ago

SDL is not a GUI library: it doesn't have any buttons, sliders or text controls. That's what this library provides.

To get on something on screen, it provides a number of backends, including SDL. However there is also one that talks to X11 directly, providing the minimum dependencies needed on Linux (as far as I'm aware).

Basically the library generates a list of drawing commands. It is up to the underlying backend (SDL, GLFW, X11, your own embedded one,....) to draw these on-screen.

ausjke3• 10 years ago

yes it's not a widget library per se, it's more of a backend library for GUI calls.

flohofwoe5• 10 years ago

I have only experience with dear-imgui so far (mentioned in the readme), but nuklear should be very similar in its requirements. You basically just need a GL context (or other 3D APIs equivalent) to write a wrapper for, SDL is sort of overkill for this.

In my case I integrated imgui with my "weekend engine" Oryol, which has a very slim wrapper around 3D APIs, and I have this running in WebGL (via emscripten) and GLES2 on Raspberry Pi 2 (should also work on the original Pi). The resulting executables are small enough for most 32-bit embedded platforms (a couple hundred KBytes), and have a much shorter list of system dependencies. On Raspberry Pi it doesn't even need a window system, it runs straight from the Linux terminal and uses the Pi's EGL wrapper.

For instance here's the WebGL imgui demo (325 kByte): http://floooh.github.io/oryol/asmjs/ImGuiDemo.html

ausjke3• 10 years ago

cool, checking it out now

ewmailing• 10 years ago

I didn't look at the demo, but that list of dependencies is not reflective of SDL.

This is what ldd on my build of SDL looks like:

    linux-vdso.so.1 =>  (0x00007ffda33d9000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff1e4c51000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff1e4a4d000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff1e4830000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff1e4628000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff1e426a000)
    /lib64/ld-linux-x86-64.so.2 (0x00007ff1e527e000)

SDL on Linux does a lot of dlopen detection at launch because it is so hard to know what kind of Linux environment you are running in at compile time. For example, you may have a X11 server, or you may be running completely on the command line without any window server. (It's really cool being able to develop for Raspberry Pi Raspbian via SDL without X11 since RAM is so limited.)

So that list is not SDL's contribution and that demo was just linking to a lot of things, most of which look unnecessary (and sloppy, though this also makes a case why people want header-only libraries because many people don't want to think about this part). For example, why is a gui demo demo linking to FLAC and all the Ogg Vorbis libraries? SDL doesn't use or depend on these either.

gjem97• 10 years ago

A couple of tweaks needed to get the example in the README to compile: wrong number of arguments in call to nk_button_text(), and need to take the address of ctx in the call to nk_end().

cm33• 10 years ago

I haven't tried this one yet, but I've tried another immediate mode ui library before and it seemed to busy loop a single cpu core. Is that normal for IM GUIs?

protomikron• 10 years ago

You may test it. It is straight-forward do build, e.g. I tested the sdl2 demo (demo/sdl/) and CPU usage was <10%.

I did not dig further, but I like the general idea, as GUI toolkits are biiiiig.

cm33• 10 years ago

I'll give it a try but <10% for an otherwise idle gui sounds like an architectural flaw/disadvantage. An idle gtk2 window sits at 0% cpu.

joeld424• 10 years ago

They typically draw/process every frame. So if you're doing a game or real-time tool, it will be part of your main loop. I wouldn't call it a "busy" loop, since usually you'd sleep or yield when done processing the frame and wait for the next frame.

There's no reason you couldn't take the same approach but only process/redraw in response to an event (e.g. on a mouse move or click). But since immediate mode GUIs tend to be used in contexts where you're already drawing every frame (games and interactive tools), people tend to use them this way as it fits the best.

The main defining characteristic of an immediate mode gui is it tries not to store state for each widget. Rather than having a large "object graph" (retained mode), you take a more functional approach and draw what you need every frame. There's much less bugs/complexity trying to keep your Model and View in sync, but somethings that need extra state (e.g. tree view expanded state) get more complicated.

jlebrech• 10 years ago

It would be nice if a GUI toolkit just targeted ncurses and you could further skin it to run in the browser, gtk or kde separately. a bit like react-native.

funkaster• 10 years ago

well, this library seems to be render agnostic:

https://github.com/vurtun/nuklear/blob/master/nuklear.h#L133...

So in theory you could just write the rendering code for ncurses, browser, etc.

hardwaresofton• 10 years ago

Rust bindings might solve rust's lack of a prominent GUI toolkit...

Or a straight port to Rust (either imgui or nuklear)

FreeFull• 10 years ago

Rust has GTK and qtquick bindings, and there is also https://github.com/pistondevelopers/conrod which also uses immediate mode. Nuklear looks like it's more capable right now than conrod, though, so Rust bindings could still be good to have.

iso-8859-13• 10 years ago

Can I use this on DOS? I am looking for a successor for http://intron-trans.hu/agui.html

joeld424• 10 years ago

Yes, you'd have to implement the drawing and input handling code but this seems like it would be a good fit. You need to implement a fair number of drawing primitives, but certainly less work than a whole GUI.

kazinator• 10 years ago

"Use at your own risk" is not an adequate license, I'm afraid.

Someone concerned about licensing can't touch this with a ten foot pole.

iso-8859-13• 10 years ago

What do you mean? It says public domain in the README.

Nuklear: A small ANSI C GUI toolkit

Related Stories