HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
vurtun
nuklear
C2016–2022
vurtun / nuklear · Archived

nuklear

A single-header ANSI C gui library

23Distinct people
28Mentions
0Explicit recommenders
14KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A single-header ANSI C gui library

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year28 dated mentions

Observed mentions: 2016-04-18 19:22:06 UTC to 2022-09-05 21:26:27 UTC.

02468102016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2022

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC615
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC404
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC1019
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC404
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC110

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Nuklear ALL DEVELOPMENT MOVED ELSEWHERE Dear visitor, this repository, issue tracker, etc. is abandoned in favor of https://github.com/Immediate-Mode-UI/Nuklear . Any activity in this issue tracker, any pull requests, etc. will be ignored. Looking forward to hearing from you in https://github.com/Immediate-Mode-UI/Nuklear Nuklear community This is a minimal state immediate mode graphical user interface toolkit written in ANSI C and licensed under public domain. It was designed as a simple embeddable user interface for application and does not have any dependencies, a default render backend 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. So instead of providing a layered library that tries to abstract over a number of platform and render backends it only focuses on the actual UI. Features Immediate mode graphical user interface toolkit Single header library Written in C89 (ANSI C) Small codebase (~18kLOC) Focus on portability, efficiency and simplicity No dependencies (not even the standard library if not wanted) Fully skinnable and customizable Low memory footprint with total memory control if needed or wanted UTF-8 support No global or hidden state Customizable library modules (you can compile and use only what you need) Optional font baker and vertex buffer output Documentation Building This library is self contained in one single header file and can be used either in header only mode or in implementation mode. The header only mode is used by default when included and allows including this header in other headers and does not contain the actual implementation. The implementation mode requires to define the preprocessor macro NK_IMPLEMENTATION in one .c/.cpp file before #includeing this file, e.g.: #define NK_IMPLEMENTATION #include "nuklear.h" IMPORTANT: Every time you include "nuklear.h" you have to define the same optional flags. This is very important not doing it either leads to compiler errors or even worse stack corruptions. Gallery Example /* init gui state */ struct nk_context ctx; nk_init_fixed(&ctx, calloc(1, MAX_MEMORY), MAX_MEMORY, &font); enum {EASY, HARD}; static int op = EASY; static float value = 0.6f; static int i = 20; if (nk_begin(&ctx, "Show", nk_rect(50, 50, 220, 220), NK_WINDOW_BORDER|NK_WINDOW_MOVABLE|NK_WINDOW_CLOSABLE)) { /* fixed widget pixel width */ nk_layout_row_static(&ctx, 30, 80, 1); if (nk_button_label(&ctx, "button")) { /* event handling */ } /* fixed widget window ratio width */ nk_layout_row_dynamic(&ctx, 30, 2); if (nk_option_label(&ctx, "easy", op == EASY)) op = EASY; if (nk_option_label(&ctx, "hard", op == HARD)) op = HARD; /* custom widget pixel width */ nk_layout_row_begin(&ctx, NK_STATIC, 30, 2); { nk_layout_row_push(&ctx, 50); nk_label(&ctx, "Volume:", NK_TEXT_LEFT); nk_layout_row_push(&ctx, 110); nk_slider_float(&ctx, 0, &value, 1.0f, 0.1f); } nk_layout_row_end(&ctx); } nk_end(&ctx); Bindings There are a number of nuklear bindings for different languges created by other authors. I cannot atest for their quality since I am not necessarily proficient in either of these languages. Furthermore there are no guarantee that all bindings will always be kept up to date: Java by Guillaume Legris D by Mateusz Muszyński Golang by golang-ui@github.com Rust by snuk182@github.com Chicken by wasamasa@github.com Nim by zacharycarter@github.com Lua LÖVE-Nuklear by Kevin Harrison MoonNuklear by Stefano Trettel Python pyNuklear by William Emerison Six (ctypes-based wrapper) pynk by nathanrw@github.com (cffi binding) CSharp/.NET by cartman300@github.com Credits Developed by Micha Mettke and every direct or indirect contributor to the GitHub. Embeds stb_texedit, stb_truetype and stb_rectpack by Sean Barrett (public domain) Embeds ProggyClean.ttf font by Tristan Grimmer (MIT license). Big thank you to Omar Cornut (ocornut@github) for his imgui library and giving me the inspiration for this library, Casey Muratori for handmade hero and his original immediate mode graphical user interface idea and Sean Barrett for his amazing single header libraries which restored my faith in libraries and brought me to create some of my own. Finally Apoorva Joshi for his singe-header file packer. License ------------------------------------------------------------------------------ This software is available under 2 licenses -- choose whichever you prefer. ------------------------------------------------------------------------------ ALTERNATIVE A - MIT License Copyright (c) 2017 Micha Mettke Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ------------------------------------------------------------------------------ ALTERNATIVE B - Public Domain (www.unlicense.org) This is free and unencumbered software released into the public domain. Anyone is free to copy, modify, publish, use,
Read the full README on GitHub

What Hacker News says

28 sources
There's really nothing preventing anyone from implementing what you're talking about. Some of it's already been done, and undone, at various times. Rio (well, devdraw, really) presents a similar drawing model to Xrender -- in fact, Plan 9's draw is listed directly as the inspiration for Xrender. If you want a fancy GUI, nuklear is ported (https://github.com/vurtun/nuklear, https://bitbucket.org/mischief/libnuklear/src/default/). Porting GTK would be similarly doable, all that's really needed is getting a GDK port to do the window management, and porting pixman and cairo for the drawing. I'm not aware of anything that devdraw+rio is missing for a working implementation. And, if you really want, there were multiple ports of X11 to plan 9 that could be revived -- Equis, for example, , so you could in theory just get did of Gnu-isms, revive o
Read the rest
ne of those unused bits of code, and run it that way. Again, there are existence proofs -- nothing about plan 9 prevents any of what you're talking, other than the people using plan 9 don't want it, and the people that want it don't want plan 9, or are almost entirely "ideas people" that aren't going to contribute a line of code towards making what they want work. Web browsers are a different story. The problem with a web browser is that a modern web browser is tens of millions of lines of code to implement a turd that's churning at an incredible rate; Last I looked, Chrome was 20 million lines of code, and needed upwards of 600 substatial out-of-tree patches to even build on BSD. And my bank's website breaks on versions below 70 or so, which means running constantly just to stay with a working version. We don't have resources to maintain that shit. For a while, there was 'linuxemu', which emulateds the linux syscall ABI, but even that had a ton of churn, and nobody put in the effort to keep up to date. Given that plan 9 is all volunteer driven (especially today), if nobody writes the code, nothing happens. > Whether they would emerge as a true believer with their faith strengthened by this trial, or as a Plan 9 heretic, would be an interesting question. The question is "what do you want out of this"? To me, this sounds like an awful lot of pointless work that makes the system quite a bit less pleasant, with code that's too big to really understand and easily debug, and a UI model that I don't even use regularly on Unix if I can avoid it. It gives me the same reaction as someone proposing making Linux compatible with MVS (IBM's mainframe operating system), complete with JCL and the data set file system.
In What Is Not in Plan Nine (2012)
I write small cross-platform applications in plain C for the same reason the author gave. I use Nuklear for the GUI; one nice thing is that it's header only, see https://github.com/vurtun/nuklear With that, I can write small apps that run macOS, iOS, Windows and Android while sharing the same C code. On macOS, iOS, and Android I use SFML to manage windows and events. Works like a charm for me and I produce lightweight apps that are fast to deploy and have no dependencies. I compile the subset I need of SFML straight into my projects.
In Projects: Back to C
Smalltalk was the first language I loved. It was great to write, but I had difficulty understanding the structure of other's code. Even with that great integrated debugger, I couldn't figure out how Morphic actually worked. These days for graphical programming, I prefer C with nuklear (https://github.com/vurtun/nuklear) over smalltalk.
In Pharo MOOC
The examples here look more interesting than libui https://github.com/vurtun/nuklear There’s a typical window app, game ui, something that looks like unreal engines visual programming. Seems like a flexible system Haven’t actually tried to use it though. That’s where it will win or lose, IMO Edit: and just got to end of the README. Bindings available for rust, python, go, lua, java and more. Gonna have to kick the tires on this one.
In Building a fast Electron app with Rust
I think overall you and I agree quite a bit. But as far as I can tell, nuklear is designed to be simple to program the implementation, and simple to program against, at the cost of some features. https://github.com/vurtun/nuklear/issues/50 Dear imgui may have some hacks as you mention to achieve features such as using tab to switch the active component, (I've never looked at the source), but it's still simple as can be to use. I'm not quite sure what you're advocating to do, but if you make a better graphical user interface framework than those other two projects, then I can't wait to see it.
In Nuklear: A single-header ANSI C GUI library

Showing the 15 most recent of 28 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.