libui

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

10,698

613

10,698

252

View on GitHub

Top Related Projects

qt

10,376

Qt binding for Go (Golang) with support for Windows / macOS / Linux / FreeBSD / Android / iOS / Sailfish OS / Raspberry Pi / AsteroidOS / Ubuntu Touch / JavaScript / WebAssembly

kivy

17,492

Open source UI framework written in Python, running on Windows, Linux, macOS, Android and iOS

fyne

24,481

Cross platform GUI toolkit in Go inspired by Material Design

imgui

59,344

Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies

JUCE

6,487

JUCE is an open-source cross-platform C++ application framework for desktop and mobile applications, including VST, VST3, AU, AUv3, LV2 and AAX audio plug-ins.

Quick Overview

libui is a portable GUI library for C that provides a native look and feel across different operating systems. It aims to offer a simple and lightweight interface for creating cross-platform graphical user interfaces without the complexity of larger frameworks.

Pros

Cross-platform compatibility (Windows, macOS, and Linux)
Native look and feel on each supported platform
Lightweight and easy to use
Written in C, making it easily bindable to other languages

Cons

Limited set of widgets compared to more comprehensive GUI frameworks
Documentation could be more extensive
Still in alpha stage, which may lead to API changes
Lacks some advanced features found in larger GUI libraries

Code Examples

Creating a simple window with a button:

#include <ui.h>

static int onClosing(uiWindow *w, void *data) {
    uiQuit();
    return 1;
}

static void onButtonClicked(uiButton *b, void *data) {
    uiMsgBox(uiWindow(data), "Hello", "Button clicked!");
}

int main(void) {
    uiInitOptions o = {0};
    uiWindow *window;
    uiButton *button;

    if (uiInit(&o) != NULL)
        return 1;

    window = uiNewWindow("libui Example", 300, 200, 1);
    uiWindowOnClosing(window, onClosing, NULL);

    button = uiNewButton("Click Me");
    uiButtonOnClicked(button, onButtonClicked, window);

    uiWindowSetChild(window, uiControl(button));
    uiControlShow(uiControl(window));

    uiMain();
    return 0;
}

Creating a simple form layout:

uiForm *form = uiNewForm();
uiFormSetPadded(form, 1);

uiEntry *nameEntry = uiNewEntry();
uiFormAppend(form, "Name:", uiControl(nameEntry), 0);

uiEntry *emailEntry = uiNewEntry();
uiFormAppend(form, "Email:", uiControl(emailEntry), 0);

uiWindowSetChild(window, uiControl(form));

Adding a menu to the window:

uiMenu *menu = uiNewMenu("File");
uiMenuItem *item = uiMenuAppendItem(menu, "Open");
uiMenuItemOnClicked(item, onOpenClicked, NULL);

uiMenuItem *quitItem = uiMenuAppendQuitItem(menu);
uiOnShouldQuit(onShouldQuit, NULL);

Getting Started

Clone the repository: git clone https://github.com/andlabs/libui.git

Build the library:

cd libui
mkdir build
cd build
cmake ..
make

Include the header in your C file: #include <ui.h>

Compile your program, linking against the built libui library:

gcc -o myprogram myprogram.c -I/path/to/libui/include -L/path/to/libui/build -lui

Remember to check the project's README and documentation for more detailed instructions and platform-specific considerations.

Competitor Comparisons

qt

10,376

Qt binding for Go (Golang) with support for Windows / macOS / Linux / FreeBSD / Android / iOS / Sailfish OS / Raspberry Pi / AsteroidOS / Ubuntu Touch / JavaScript / WebAssembly

Pros of Qt

More comprehensive and feature-rich GUI toolkit
Extensive documentation and large community support
Cross-platform compatibility with native look and feel

Cons of Qt

Larger footprint and resource usage
Steeper learning curve due to its complexity
Licensing considerations for commercial applications

Code Comparison

Qt:

app := widgets.NewQApplication(len(os.Args), os.Args)
window := widgets.NewQMainWindow(nil, 0)
button := widgets.NewQPushButton2("Click me", nil)
window.SetCentralWidget(button)
window.Show()
app.Exec()

libui:

ui.Main(func() {
    window := ui.NewWindow("Hello", 200, 100, false)
    button := ui.NewButton("Click Me")
    window.SetChild(button)
    window.OnClosing(func(*ui.Window) bool {
        ui.Quit()
        return true
    })
    window.Show()
})

Qt offers a more object-oriented approach with separate application and window objects, while libui provides a simpler, more compact syntax. Qt's code structure reflects its larger feature set, whereas libui focuses on minimalism and ease of use.

kivy

17,492

Open source UI framework written in Python, running on Windows, Linux, macOS, Android and iOS

Pros of Kivy

Cross-platform support for desktop and mobile (iOS, Android)
Rich set of UI widgets and tools for creating complex interfaces
Active community and extensive documentation

Cons of Kivy

Steeper learning curve, especially for those new to Python
Larger file sizes and resource usage compared to native apps

Code Comparison

Kivy:

from kivy.app import App
from kivy.uix.button import Button

class MyApp(App):
    def build(self):
        return Button(text='Hello World')

MyApp().run()

libui:

#include "ui.h"

static int onClosing(uiWindow *w, void *data) {
    uiQuit();
    return 1;
}

int main(void) {
    uiInit(NULL);
    uiWindow *window = uiNewWindow("Hello", 200, 100, 1);
    uiWindowOnClosing(window, onClosing, NULL);
    uiControlShow(uiControl(window));
    uiMain();
    return 0;
}

Key Differences

Kivy uses Python, while libui uses C
Kivy offers more advanced UI capabilities and animations
libui provides a more native look and feel on each platform
Kivy has a larger ecosystem and community support
libui is lighter-weight and may be better for simple applications

wxWidgets

6,017

Cross-Platform C++ GUI Library

Pros of wxWidgets

More mature and feature-rich, with a long history of development
Extensive documentation and large community support
Cross-platform support for a wider range of operating systems

Cons of wxWidgets

Larger codebase and steeper learning curve
Heavier resource usage and larger binary sizes
Less modern-looking UI elements by default

Code Comparison

wxWidgets:

#include <wx/wx.h>

class MyFrame : public wxFrame {
public:
    MyFrame() : wxFrame(NULL, wxID_ANY, "Hello World") {
        wxButton *button = new wxButton(this, wxID_ANY, "Click Me");
    }
};

libui:

#include "ui.h"

static int onClosing(uiWindow *w, void *data) {
    uiQuit();
    return 1;
}

int main(void) {
    uiInitOptions o = {0};
    uiInit(&o);
    uiWindow *window = uiNewWindow("Hello World", 200, 100, 0);
    uiButtonOnClicked(uiNewButton("Click Me"), NULL, NULL);
    uiWindowOnClosing(window, onClosing, NULL);
    uiControlShow(uiControl(window));
    uiMain();
    return 0;
}

wxWidgets offers a more object-oriented approach with C++, while libui provides a simpler C-based API. wxWidgets requires more boilerplate code for basic functionality, but offers greater flexibility for complex applications. libui's code is more concise and straightforward for simple GUI tasks.

fyne

24,481

Cross platform GUI toolkit in Go inspired by Material Design

Pros of Fyne

Cross-platform GUI toolkit with native look and feel
Rich set of widgets and layouts out of the box
Active development and community support

Cons of Fyne

Larger binary sizes due to bundled resources
Steeper learning curve for developers new to Go

Code Comparison

Fyne example:

package main

import (
    "fyne.io/fyne/v2/app"
    "fyne.io/fyne/v2/widget"
)

func main() {
    myApp := app.New()
    myWindow := myApp.NewWindow("Hello")
    myWindow.SetContent(widget.NewLabel("Hello Fyne!"))
    myWindow.ShowAndRun()
}

libui example:

#include <ui.h>

int main(void) {
    uiInitOptions o = {0};
    uiInit(&o);
    uiWindow *w = uiNewWindow("Hello", 200, 100, 0);
    uiLabel *l = uiNewLabel("Hello libui!");
    uiWindowSetChild(w, uiControl(l));
    uiControlShow(uiControl(w));
    uiMain();
    return 0;
}

Summary

Fyne offers a more Go-centric approach with a richer set of widgets and active development. It's suitable for larger applications but may have larger binaries. libui provides a simpler, lightweight option with C-style programming, potentially resulting in smaller executables but with fewer built-in features.

imgui

59,344

Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies

Pros of imgui

Immediate mode GUI, allowing for more dynamic and flexible interfaces
Lightweight and easy to integrate into existing projects
Extensive documentation and examples

Cons of imgui

Requires more manual control and state management
Less native look and feel compared to platform-specific UIs
May have higher performance overhead for complex interfaces

Code Comparison

imgui:

ImGui::Begin("My Window");
if (ImGui::Button("Click me!")) {
    // Handle button click
}
ImGui::End();

libui:

uiButton *button = uiNewButton("Click me!");
uiButtonOnClicked(button, onButtonClicked, NULL);
uiBoxAppend(box, uiControl(button), 0);

Key Differences

imgui uses an immediate mode approach, redrawing the entire UI each frame
libui follows a more traditional retained mode GUI paradigm
imgui is primarily designed for game development and debugging tools
libui aims to provide a native look and feel across different platforms

Use Cases

imgui: Game development, debug interfaces, rapid prototyping
libui: Cross-platform desktop applications, native-looking GUIs

Both libraries have their strengths and are suited for different scenarios. The choice between them depends on the specific requirements of your project, such as performance needs, desired look and feel, and development workflow.

JUCE

6,487

JUCE is an open-source cross-platform C++ application framework for desktop and mobile applications, including VST, VST3, AU, AUv3, LV2 and AAX audio plug-ins.

Pros of JUCE

Comprehensive framework with audio, GUI, and plugin development capabilities
Cross-platform support for desktop and mobile applications
Large community and extensive documentation

Cons of JUCE

Steeper learning curve due to its extensive feature set
Larger codebase and potential overhead for simpler projects
Commercial licensing required for some use cases

Code Comparison

JUCE example (basic window):

class MainComponent : public juce::Component
{
public:
    MainComponent() { setSize(300, 200); }
    void paint(juce::Graphics& g) override
    {
        g.fillAll(juce::Colours::white);
        g.drawText("Hello, World!", getLocalBounds(), juce::Justification::centred, true);
    }
};

libui example (basic window):

static int onClosing(uiWindow *w, void *data)
{
    uiQuit();
    return 1;
}

static uiWindow *mainwin;

int main(void)
{
    uiInitOptions o = {0};
    const char *err = uiInit(&o);
    if (err != NULL) { /* handle error */ }
    mainwin = uiNewWindow("libui Example", 300, 200, 1);
    uiWindowOnClosing(mainwin, onClosing, NULL);
    uiControlShow(uiControl(mainwin));
    uiMain();
    return 0;
}

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

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 that the old API wouldn't allow. You can read on the whole API here. There is also a new examples for it: drawtext, which shows the whole API at a glance. It doesn't yet support measuring or manipulating text, nor does it currently support functions that would be necessary for things like text editors; all of this will be added back later.
- libui also now uses my utf library for UTF-8 and UTF-16 processing, to allow consistent behavior across platforms. This usage is not completely propagated throughout libui, but the Windows port uses it in most places now, and eventually this will become what libui will use throughout.
- Also introduced a formal set of contribution guidelines, see CONTRIBUTING.md for details. They are still WIP.
17 February 2018
- The longstanding Enter+Escape crashes on Windows have finally been fixed (thanks to @lxn).
- Alpha 3.5 is now here. This is a quickie release primiarly intended to deploy the above fix to package ui itself. It is a partial binary release; sorry! More new things will come in the next release, which will also introduce semver (so it will be called v0.4.0 instead).
- Alpha 3.5 also includes a new control gallery example. The screenshots below have not been updated yet.

Old announcements can be found in the NEWS.md file.

Runtime Requirements

Windows: Windows Vista SP2 with Platform Update or newer
Unix: GTK+ 3.10 or newer
Mac OS X: OS X 10.8 or newer

Build Requirements

All platforms:
- Meson 0.48.0 or newer
- Any of Meson's backends; this section assumes you are using Ninja, but there is no reason the other backends shouldn't work.
Windows: either
- Microsoft Visual Studio 2013 or newer (2013 is needed for va_copy()) â you can build either a static or a shared library
- MinGW-w64 (other flavors of MinGW may not work) â you can only build a static library; shared library support will be re-added once the following features come in:
  - Isolation awareness, which is how you get themed controls from a DLL without needing a manifest
Unix: nothing else specific
Mac OS X: nothing else specific, so long as you can build Cocoa programs

Building

libui uses only the standard Meson build options, so a libui build can be set up just like any other:

$ # you must be in the top-level libui directory, otherwise this won't work
$ meson setup build [options]
$ ninja -C build

Once this completes, everything will be under build/meson-out/. (Note that unlike the previous build processes, everything is built by default, including tests and examples.)

The most important options are:

--buildtype=(debug|release|...) controls the type of build made; the default is debug. For a full list of valid values, consult the Meson documentation.
--default-library=(shared|static) controls whether libui is built as a shared library or a static library; the default is shared. You currently cannot specify both, as the build process changes depending on the target type (though I am willing to look into changing things if at all possible).
-Db_sanitize=which allows enabling the chosen sanitizer on a system that supports sanitizers. The list of supported values is in the Meson documentation.
--backend=backend allows using the specified backend for builds instead of ninja (the default). A list of supported values is in the Meson documentation.

Most other built-in options will work, though keep in mind there are a handful of options that cannot be overridden because libui depends on them holding a specific value; if you do override these, though, libui will warn you when you run meson.

The Meson website and documentation has more in-depth usage instructions.

For the sake of completeness, I should note that the default value of --layout is flat, not the usual mirror. This is done both to make creating the release archives easier as well as to reduce the chance that shared library builds will fail to start on Windows because the DLL is in another directory. You can always specify this manually if you want.

Backends other than ninja should work, but are untested by me.

Installation

Meson also supports installing from source; if you use Ninja, just do

$ ninja -C build install

When running meson, the --prefix option will set the installation prefix. The Meson documentation has more information, and even lists more fine-grained options that you can use to control the installation.

Arch Linux

Can be built from AUR: https://aur.archlinux.org/packages/libui-git/

Documentation

Needs to be written. Consult ui.h and the examples for details for now.

Language Bindings

libui was originally written as part of my package ui for Go. Now that libui is separate, package ui has become a binding to libui. As such, package ui is the only official binding.

Other people have made bindings to other languages:

Language	Bindings
C++	libui-cpp, cpp-libui-qtlike
C# / .NET Framework	LibUI.Binding
C# / .NET Core	DevZH.UI, SharpUI, TCD.UI
CHICKEN Scheme	wasamasa/libui
Common Lisp	jinwoo/cl-ui
Crystal	libui.cr, hedron
D	DerelictLibui (flat API), libuid (object-oriented)
Euphoria	libui-euphoria
Harbour	hbui
Haskell	haskell-libui
JavaScript/Node.js	libui-node, libui.js (merged into libui-node?), proton-native, vuido
Julia	Libui.jl
Kotlin	kotlin-libui
Lua	libuilua, libui-lua, lui, lui
Nim	ui
Perl6	perl6-libui
PHP	ui
Python	pylibui
Ruby	libui-ruby, libui
Rust	libui-rs
Scala	scalaui
Swift	libui-swift

Frequently Asked Questions

Why does my program start in the background on OS X if I run from the command line?

OS X normally does not start program executables directly; instead, it uses Launch Services to coordinate the launching of the program between the various parts of the system and the loading of info from an .app bundle. One of these coordination tasks is responsible for bringing a newly launched app into the foreground. This is called "activation".

When you run a binary directly from the Terminal, however, you are running it directly, not through Launch Services. Therefore, the program starts in the background, because no one told it to activate! Now, it turns out there is an API that we can use to force our app to be activated. But if we use it, then we'd be trampling over Launch Services, which already knows whether it should activate or not. Therefore, libui does not step over Launch Services, at the cost of requiring an extra user step if running directly from the command line.

Contributing

See CONTRIBUTING.md.

Screenshots

From examples/controlgallery:

Windows

Unix

OS X

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot