HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
andlabs
libui
C2016–2026
andlabs / libui

libui

Simple and portable (but not inflexible) GUI library in C that uses the native GUI technologies of each platform it supports.

51Distinct people
71Mentions
0Explicit recommenders
10.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Simple and portable (but not inflexible) GUI library in C that uses the native GUI technologies of each platform it supports.

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 year71 dated mentions

Observed mentions: 2016-05-20 03:29:18 UTC to 2026-03-01 23:33:14 UTC.

01020302016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 14 mentions; 1 submissions, 13 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 27 mentions; 2 submissions, 25 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

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 UTC14113
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC817
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC27225
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC707
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC615
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC514
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

From the project README

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

Read the project’s introduction
libui: a portable GUI library for C This README is being written. Status It has come to my attention that I have not been particularly clear about how usable or feature-complete libui is, and that this has fooled many people into expecting more from libui right this moment than I have explicitly promised to make available. I apologize for not doing this sooner. libui is currently mid-alpha software. Much of what is currently present runs stabily enough for the examples and perhaps some small programs to work, but the stability is still a work-in-progress, much of what is already there is not feature-complete, some of it will be buggy on certain platforms, and there's a lot of stuff missing. In short, here's a list of features that I would like to add to libui, but that aren't in yet: trees clipboard support, including drag and drop more and better dialogs printing accessibility for uiArea and custom controls document-based programs tighter OS integration (especially for document-based programs), to allow programs to fully feel native, rather than merely look and act native better support for standard dialogs and features (search bars, etc.) OpenGL support In addition, here is a list of issues generalizing existing problems. Furthermore, libui is not properly fully documented yet. This is mainly due to the fact that the API was initially unstable enough so as to result in rewriting documentation multiple times, in addition to me not being happy with really any existing C code documentation tool. That being said, I have started to pin down my ideal code documentation style in parts of ui.h, most notably in the uiAttributedString APIs. Over time, I plan on extending this to the rest of the headers. You can also use the documentation for libui's Go bindings as a reference, though it is somewhat stale and not optimally written. But libui is not dead; I am working on it whenever I can, and I hope to get it to a point of real quality soon! News Note that today's entry (Eastern Time) may be updated later today. 7 April 2019 The build system has been switched to Meson. See below for instructions. This change was made because the previous build system, CMake, caused countless headaches over trivial issues. Meson was chosen due to how unproblematic setting up libui's build just right was, as well as having design goals that are by coincidence closely aligned with what libui wants. Travis CI has been replaced with Azure Pipelines and much of the AppVeyor CI configuration was integrated into the Azure Pipelines configuration. This shouldn't affect most developers. 1 September 2018 Alpha 4.1 is here. This is an emergency fix to Alpha 4 to fix uiImageAppend() not working as documented. It now works properly, with one important difference you'll need to care about: it now requires image data to be alpha-premultiplied. In addition, uiImage also is implemented slightly more nicely now, and ui.h has minor documentation typo fixes. Alpha 4.1 also tries to make everything properly PIC-enabled. 10 August 2018 Alpha 4 is finally here. Everything from Alpha 3.5 and what's listed below is in this release; the two biggest changes are still the new text drawing API and new uiTable control. In between all that is a whole bunch of bugfixes, and hopefully more stability too. Thanks to everybody who helped contribute! Alpha 4 should hopefully also include automated binary releases via CI. Thanks to those who helped set that up! 8 August 2018 Finally introduced an API for loading images, uiImage, and a new control, uiTable, for displaying tabular data. These provide enough basic functionality for now, but will be improved over time. You can read the documentation for the new features as they are here. Thanks to everyone who helped get to this point, in particular @bcampbell for the initial Windows code, and to everyone else for their patience! 30 May 2018 Merged the previous Announcements and Updates section of this README into a single News section, and merged the respective archive files into a single NEWS.md file. 16 May 2018 Thanks to @parro-it and @msink, libui now has better CI, including AppVeyor for Windows CI, and automated creation of binary releases when I make a tagged release. 13 May 2018 Added new functions to work with uiDateTimePickers: uiDateTimePickerTime(), uiDateTimePickerSetTime(), and uiDateTimePickerOnChanged(). These operate on standard <time.h> struct tms. Thanks @cody271! Release builds on Windows with MSVC should be fixed now; thanks @l0calh05t, @slahn, @mischnic, and @zentner-kyle. 12 May 2018 GTK+ and OS X now have a cleaner build process for static libraries which no longer has intermediate files and differing configurations. As a result, certain issues should no longer be present. New naming rules for internal symbols of libui have also started being drafted; runtime symbols and edge cases still need to be handled (and the rules applied to Windows) before this can become a regular thing. 2 May 2018 On Windows, you no longer need to carry around a libui.res file with static builds. You do need to link in the appropriate manifest file, such as the one in the windows/ folder (I still need to figure out exactly what is needed apart from the Common Controls v6 dependency, or at least to create a complete-ish template), or at least include it alongside your executables. This also means you should no longer see random cmake errors when building the static libraries. 18 April 2018 Introduced a new uiTimer() function for running code on a timer on the main thread. (Thanks to @cody271.) Migrated all code in the common/ directory to use uipriv prefixes for everything that isn't static. This is the first step toward fixing static library oddities within libui, allowing libui to truly be safely used as either a static library or a shared library. 18 March 2018 Introduced an all-new formatted text API that allows you to process formatted text in ways tha
Read the full README on GitHub

What Hacker News says

71 sources
Some other options. https://github.com/andlabs/libui > Simple and portable (but not inflexible) GUI library in C that uses the native GUI technologies of each platform it supports. Missing a lot of desktop features and abandoned. https://wxwidgets.org/ > wxWidgets is a C++ library that lets developers create applications for Windows, macOS, Linux and other platforms with a single code base. https://github.com/fltk/fltk > FLTK provides modern GUI functionality without bloat ... Not native, but small, dependable and cross-platform.
In PureBasic: The Quiet Survivor
You can kind of see the desktop UI train wreck in real time here. We started with simple stable APIs for a common look and feel. For a while these were evolved and made available in other languages. This was back when native apps were consistent and intuitive and you could… uhh… actually write and ship them without bundling giant runtimes or checking a huge compatibility matrix. Then around 2012 the train rounds the bend and screeeeech it hits some bad track and starts to derail. UI starts trying to emulate the web, a terrible UI platform, and sane compositional UI libraries and APIs are abandoned in favor of XML soup. Since this stuff is a trash fire, this is followed by multiple incompatible attempts to replace or fix this. Most of these are abandoned dead ends. Meanwhile we also abandon the incredibly productive point and click WYSIWYG
Read the rest
UI builders because apparently people want to write XML puke instead. Meanwhile the dev community just said fuck it and went to Electron, creating today’s world where a “hello world” app with an OK button is hundreds of megabytes and has to load an entire private copy of a language runtime and rendering engine. Versions of this comedy of errors have occurred on every other platform, and of course there has been little effort to create a cross platform UI API that’s sane beyond Qt (with its own problems) and dozens of half completed OSS projects. So enjoy Electron I guess. There was one sane human being who tried to do this a while ago: https://github.com/andlabs/libui It’s the only sane desktop UI project I’ve seen in almost 20 years, an attempt to create an actual cross platform common API wrapping well behaved mature native APIs. Like a modern reboot of wxWidgets, an also sane but old and dusty project. But it’s abandoned of course, likely too difficult for one dev and nobody is going to provide financial support for anything that sane. It’s neither trendy nor profitable nor a wedge to try to ram a new language down our throats (e.g. Flutter and Dart). Maybe AI will get good enough some day that we can use it to do a thing like that. I do have this weird idea that we might be able to use really good code generating AI some day to do a lot of very sane but boring and unprofitable things that would make computing a lot better.
In Short history of all Windows UI frameworks and libraries
I don't know about non-native, but LibUI offers native GUI in C: https://github.com/andlabs/libui Better yet, it has excellent DSLs that make it possible to build desktop apps in a way similar to HTML, but much better due to keeping all code dynamic in one language (no static/dynamic multi-language separation/mixing dissonance): https://github.com/AndyObtiva/glimmer-dsl-libui By the way, with the `area` control (widget), you can actually make your app look like anything you want. It lets you do arbitrary painting of vertex graphics while providing keyboard and mouse event listener support to let the user interact with the user-interface, so the sky is the limit. Also, you can simply compose new custom controls from `area` controls and just work with the new custom controls as higher constructs to build your apps. In fact, most native GUI
Read the rest
toolkits provide non-native support for building any widget you want, so do not think that native widgets limit you. They don't. They in fact provide a better user experience for cases that could utilize predictable-looking basic GUI for non-computer-savvy people while still offering you the extra option of building non-native widgets when you need them.
In Ask HN: Is there any cross platform non native GUI written in C that looks good?
My biggest gripe with virtually every UI is that it forces you to learn yet another language just to code with it. Why can't there be UI APIs that work across languages like there is with loads of other stuff? We have this for networking, disk I/O, common OS operations, and even 3D graphics, but for some reason 2D user interfaces just can't be presented in this way. Why can't there be an OpenGL-like thing for desktop-style and mobile-style UIs that presents the most universal design patterns via standard APIs and allows access to OS or UI-layer specific extensions? How hard is this? There is one lone project by one developer that seems to have been trying to do this, but it seems dead. Probably far larger than one developer can tackle in their spare time, but the effort is admirable: https://github.com/andlabs/libui This one person someho
Read the rest
w gets it. Back to the topic at hand. It's not that Kotlin is a bad language. I've heard it's quite nice. The problem is that it's yet another language which means more cognitive load, more build complexity, and so on. If my project is in Go or C++ or Rust, I want my UI in Go or C++ or Rust. All that being said, I use Jetbrains IDEs and am generally impressed. They make very high quality stuff, so this merits at least a look.
In JetBrains Compose
I don't want a new native UI for Windows. I want a cross platform UI. I am NOT developing the same GUI N times for N different platforms. No way. Even very large companies like Slack are refusing to do that. They have the resources to have three or four parallel dev teams but why? I don't care how nifty, pretty, fast, or modern this new UI is. It's not cross platform therefore it does not exist. This is not a technical problem. Check this project out: https://github.com/andlabs/libui Yes it's minimal and rough around the edges, but it's the work of one developer in their spare time. If one developer hacking away in the evenings can do that, then there is no excuse. If OS vendors keep insisting on being special and trying to herd developers into making OS-specific apps, developers will keep going to bloated but portable alternatives like E
Read the rest
lectron and Qt. Why is every new app an Electron app? Don't blame developers or Electron. Blame OS vendors. It's 2020. We have common portable APIs for threads, networking, even 3D graphics, but not 2D GUIs. It's easier to write a portable cross platform 3D rendering engine than it is to write a portable cross platform app with a menu, a box, and a button. It's just offensive at this point.
In WinUI, The modern native UI platform of Windows

Showing the 15 most recent of 71 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.