libui-ng: a portable GUI library for C

Related tags

GUI libui-ng

libui-ng: a portable GUI library for C

Fork of andlabs/libui. This README is being written.
Build Status, GitHub Actions



Old announcements can be found in the 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


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.


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:


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, 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.

See also this and this.




From examples/controlgallery:




  • Table selection API

    Table selection API

    This is an effort to provide a table selection API as was suggested in libui#413.

    I have made some alterations to the original proposal.

    This introduces 5 different table selection modes:

    uiTableSelectionModeNone,       //!< Allow no row selection.                                
    uiTableSelectionModeZeroOrOne,  //!< Allow zero or one row to be selected.                  
    uiTableSelectionModeOne,        //!< Allow for exactly one row to be selected.              
    uiTableSelectionModeZeroOrMany, //!< Allow zero or many (multiple) rows to be selected. 

    With a get/set function:

    uiTableSelectionMode uiTableGetSelectionMode(uiTable *t);
    void uiTableSetSelectionMode(uiTable *t, uiTableSelectionMode mode);

    And then three functions to set a selection changed callback and get/free the actual selection:

    void uiTableOnSelectionChanged(uiTable *t, void (*f)(uiTable *t, void *data), void *data);
    uiTableSelection* uiTableGetSelection(uiTable *t);
    void uiTableSetSelection(uiTable *t, uiTableSelection *selection);
    void uiFreeTableSelection(uiTableSelection* s);

    uiTableSelection struct:

    struct uiTableSelection
        int NumRows;
        int *Rows;

    I did some testing with the big tables (100k rows). Selecting all rows at once and having the tester print the rows on the terminal still has IMO very acceptable performance. Only minimal lag on my system. An iterator style API would be nice in the future though.

    ~~There is still one inconsistency across platforms remaining as far as I can tell:~~ ~~Windows and unix both emit a selection changed when clicking on an already selected row on uiTableSelectionModeZeroOrMany, darwin will not. ~~Should be try to suppress this?~~ I've managed to suppress this for all other modes, for multi select I fear we might need to cache the entire selection and compare possibly on each selection change. Not sure what that would mean for performance.~~

    ~~All other edge cases should be documented in the API docs.~~

    Otherwise this works for me on all officially supported platforms. Wine sadly does not work, ~~see upstream bug report. I've sent in patches for fixing wine, so far no luck.~~

    I've kept my commits intact, if need be I can squash.

    ~~There are a few things I am not quite happy about:~~

    • ~~Inefficiencies in the unix & darwin code. We need to iterate over the selection multiple times to convert formats~~
    • ~~Should uiTableSelectionCurrentSelection return a value to indicate malloc errors? assert is not acceptable. Or is the current note in ui.h sufficient, requiring users to check BOTH rows != NULL and numRows > 0?~~

    ~~My question is: are these inefficiencies acceptable? I was wondering if it would be possible to provide some type of iterator API? I am however not sure if it is even possible or if it would really lead to any significant gains.~~

    ~~Then there seems to be a bug on windows (win7). Can anybody reproduce? Go to tester, page16, click Multiple Selection, try to edit a cell in the editable column. On many occasions the cell will loose focus by itself and editing will be stopped. Interestingly enough this does not happen on wine. Can anybody reproduce this on newer windows versions?~~

    ~~Edit: Windows default behavior when clicking an already selected/focused row seems to be: Send a deselect signal to for all items nm->iItem == -1 and then send another select signal for the row that was already selected/focused. I replicated this with the windows sample virtual list~~

    opened by szanni 21
  • [Old PR libui#514] Add new API functions to get/set table column widths. #514

    [Old PR libui#514] Add new API functions to get/set table column widths. #514

    Old PR libui#514

    Proposal to add API functions to get and set table column widths:

    int uiTableColumnWidth(uiTable *t, int column);
    void uiTableColumnSetWidth(uiTable *t, int column, int width);

    Same as in #24 we need a way to identify columns. I used the same mechanism of identifying columns by index position when added for the time being.

    Implementations provided for all platforms (darwin, unix, windows) with a test bed in page16.

    old repo 
    opened by szanni 14
  • [Old PR libui#508] Add advanced uiTable test suite to page17.

    [Old PR libui#508] Add advanced uiTable test suite to page17.

    I decided to add a more complete uiTable testing suite:

    This adds two uiTables backed by the same uiTableModel. Additionally it provides functions to insert and delete rows manually.

    Issues like the one in #17 libui#507 can be nicely exhibited through the upgraded tester.

    old repo 
    opened by szanni 12
  • [POC] Unit testing with cmocka

    [POC] Unit testing with cmocka

    As I mentioned in #74 I would like some way of automatically testing at least some of the library code.

    This is a first proof of concept, testing getters/setters, out of bounds values etc. I find this especially useful in making sure the API claims, eg. here #96 actually hold true.

    ~~You will need to install cmocka... via your package manager. Most repos seem to have it. For mingw, install the appropriate mingw package. Otherwise this will fail horribly.~~

    Current state:

    • [x] unix
    • [x] darwin
    • [x] windows
      • [x] mingw
      • [x] msvc


    Meson now force compiles cmocka locally, installed versions of cmocka should be ignored completely. This sadly requires bumping the meson version to 58.To test, run the resulting unit executable or meson test -C build --verbose.

    ~~macOS still fails after the first test due to #118.~~


    ~~Install cmocka. Run the resulting unit executable.~~


    ~~Install cmocka. I did this via brew. Sadly brew does not install fat binaries, so I need to remove the arm64 targets from the

    -       libui_project_compile_args += ['-arch', 'arm64', '-arch', 'x86_64']
    -       libui_project_link_args += ['-arch', 'arm64', '-arch', 'x86_64']
    +       libui_project_compile_args += ['-arch', 'x86_64']
    +       libui_project_link_args += ['-arch', 'x86_64']

    ~~Again, run the resulting unit executable. It currently only runs the first test, then fails. I guess the uiUnInit() does not correctly do its job.~~ ~~Can you open and close an cocoa app twice from the same process? I will try come up with some simpler test to verify and open an issue.~~

    In theory we could probably reuse the same window over and over. But I think this might be a bug, so I'm leaving it in the POC.



    ~~Install mingw-w64-cmocka, or whatever the naming convention is on your system. Build. See it fail.

    ~~Currently meson decides to pull in the dynamic library of cmocka. The magic we need is in test/unit/ where we actually want:~~

    -cmocka_deps = dependency('cmocka', version : '>=1.0.0')
    +cmocka_deps = dependency('cmocka', version : '>=1.0.0', static: true)

    ~~which sadly fails on my system. Cmocka seemingly does not produce a libcmocka.a but instead a libcmocka-static.a. I am unclear if this is a cmocka upstream issue or a problem with the Archlinux package I use. Could somebody on another Linux distribution confirm?.~~

    ~~Or is there some way to coerce meson to go looking for a lib-static.a as well? Unclear. There seem to be quite a few open meson tickets regarding static linking.~~

    ~~Linking manually to libcmocka-static.a does work though, from the build directory:~~

    x86_64-w64-mingw32-g++  -o meson-out/unit.exe meson-out/test_unit_resources.rc_resources.o meson-out/unit.exe.p/main.c.obj -flto -Wl,--allow-shlib-undefined -Wl,-O1 -static -static-libgcc -static-libstdc++ -Wl,-O1,--sort-common,--as-needed -fstack-protector -Wl,--start-group meson-out/libui.a -luser32 -lkernel32 -lgdi32 -lcomctl32 -luxtheme -lmsimg32 -lcomdlg32 -ld2d1 -ldwrite -lole32 -loleaut32 -loleacc -luuid -lwindowscodecs -L/usr/x86_64-w64-mingw32/lib -l:libcmocka-static.a -luser32 -lkernel32 -lgdi32 -lcomctl32 -luxtheme -lmsimg32 -lcomdlg32 -ld2d1 -ldwrite -lole32 -loleaut32 -loleacc -luuid -lwindowscodecs -Wl,--end-group -mconsole

    ~~and then running ./meson-out/unit.exe does work with wine! Great.~~


    ~~I have no idea where to even start.~~


    ~~A lot to still be done. I am happy for any pointers. Looking at all the issues, I am wondering if pulling in cmocka via a git submodule and building it... might not be easier. As much as I had submodules, maybe it would keep the library more cohesive. especially with msvc in mind? Again: open for suggestions.~~

    opened by szanni 10
  • Doxygen documentation.

    Doxygen documentation.

    I know there have been numerous attempts at annotating the library, here is another one.

    Instead of dumping everything into one commit, I decided to go by component.

    Documented (missing proper callback formatting)

    • [x] uiWindow
    • [x] uiButton
    • [x] uiBox
    • [x] uiCheckbox
    • [x] uiEntry
    • [x] uiLabel
    • [x] uiTab
    • [x] uiGroup
    • [x] uiSpinbox
    • [x] uiSlider
    • [x] uiProgressBar
    • [x] uiSeparator
    • [x] uiCombobox
    • [x] uiEditableCombobox
    • [x] uiRadioButtons
    • [x] uiDateTimePicker
    • [x] uiMultilineEntry
    • [x] uiOpenFile() uiOpenFolder() uiSaveFile() uiMsgBox() uiMsgBoxError()
    • [x] uiImage
    • [x] uiGrid
    • [x] uiColorButton
    • [x] uiForm
    • [x] uiFontButton
    • [x] uiMenuItem
    • [x] uiMenu
    • [x] uiTable & friends


    • [x] Annotate all uiWindow functions that are merely hints on unix as such
    • [x] Document callbacks

    Supercedes #64 Related to #3 #92

    opened by szanni 8
  • New examples

    New examples

    • hello-world: Display a window. Using as few statements as possible may not be the best practice.
    • hello-window: Display a window and add a label to the window, using best practices where possible.

    TODO: Add more standalone hello-widgets examples.

    opened by inkydragon 8
  • Update entry.cpp and multilineentry.cpp on Windows

    Update entry.cpp and multilineentry.cpp on Windows

    I'm not sure if it is better etiquette to make individual PRs for each of my suggested changes, but there are multiple small changes so I decided to group them into a single PR.

    Here, I made a small refactor to make the branches taken a little more clear. I made the same change in multilineentry.cpp.

    Here, I replaced a PostMessageW call with the corresponding macro: in this case, Edit_SetSel. I believe switching from PostMessageW to macros where possible was mentioned previously as an issue.

    This should be equivalent to the original code but is a little less verbose.

    I made a few changes here. Mainly, I addressed the comments left previously by preserving the current text selection after appending text. I also made a few macro replacements where possible, and I introduced a new function windowTextLen in text.cpp that returns the text length of an edit control. I noticed we were querying text length manually in some places, so I decided to make a dedicated function.

    opened by norepimorphism 7
  • Add table on row clicked and double clicked callbacks.

    Add table on row clicked and double clicked callbacks.

    Proposal to add two new API functions to set a callback for when a user clicks and double clicks a table row.

    void uiTableOnRowClicked(uiTable *t, void (*f)(uiTable *t, int row, void *data), void *data);
    void uiTableOnRowDoubleClicked(uiTable *t, void (*f)(uiTable *t, int row, void *data), void *data);

    Implementations provided for darwin, unix, and windows. A small sample usage is provided on page16.

    Two platform inconsistencies I found while testing:

    1. Unix will send two uiTableOnRowClicked events when double clicking before the uiTableOnRowDoubleClicked event. Windows and Mac will only send one.
    2. Mac will not select a row when ticking a checkbox, hence no uiTableOnRowClicked is sent. Unix and Windows select the row (first), send a uiTableOnRowClicked event and then send a uiTableValueChanged event.

    My suggestions:

    1. Can be ignored for now, as this will be automatically fixed once we switch to GtkGesture based events Gtk >= 3.14 or at the latest Gtk4. A working fix that requires Gtk >= 3.14 can be found here.
    2. Not sure what to do about the differing behavior for mac in general, this should possibly be raised as an issue on its own? Comments welcome.

    This would supersede #44, adding a differentiation between single and double click and fixing all problems related to keyboard events on the unix side as well (by not implicitly adding any handlers). Supersedes old PR libui#516

    opened by szanni 6
  • Can we have uiSliderOnReleased?

    Can we have uiSliderOnReleased?

    Is it possible to add function uiSliderOnReleased? In Qt, I can use SIGNAL(sliderReleased()) to detect when user finishes dragging the slider. Thanks!

    opened by MikeWang000000 6
  • Add proper copyright attribution.

    Add proper copyright attribution.

    I think we need a way of properly assigning copyright, similar to how other open source projects handle this.

    I would suggest either an AUTHORS file or IMO even better: listing contributors at the bottom of the LICENSE file.

    The copyright in the LICENSE file has already been changed to Copyright (c) 2022 libui-ng authors. How about adding a list of authors at the bottom of said file?

    Copyright (c) 2022 libui-ng authors
    First Last

    Somebody would have to go through the git log and add the names. New contributors would add their name themselves (remark in needed).

    opened by szanni 6
  • [Old PR libui#512] Add new API functions to get and set the visibility of table headers.

    [Old PR libui#512] Add new API functions to get and set the visibility of table headers.

    Old PR libui#512

    Proposal for two new API additions to un/hide table headers:

    int uiTableHeaderVisible(uiTable *t);
    void uiTableHeaderSetVisible(uiTable *t, int visible);

    This was one of the requests in the table master issue.


    Added API functions: uiTableHeaderVisible() to determine whether the table header is visible. uiTableHeaderSetVisible() to set the visibility of the table header.

    Implementation provided for unix, darwin, and windows.

    Notes: as darwin does not provide an API for hiding or recreating the table header I opted for saving a reference and restoring that when the visibility is set back to true. Setting the header to nil to hide it is the suggested method for hiding the header according to the docs.

    old repo 
    opened by szanni 6
  • darwin: Memory leak and other problems when not creating a window.

    darwin: Memory leak and other problems when not creating a window.

    This may be rare in practice, but the behavior of the library is kind of funky when not creating a window and running uiMain(). First, the application can not be terminated. The menu item for Quit is disabled and doing an alt click on the application itself and pressing quit results only in a NSLog 2022-12-22 16:14:57.866 window[43519:1828200] in applicationShouldTerminate:.

    The other thing it triggers is a memory leak when running uiInit(); uiUninit(); uiInit(); uiUninit() in succession, as is done in the unit tests

    Run leaks --atExit -- ./build/meson-out/unit:

    Process:         unit [43429]
    Path:            /Users/USER/*/unit
    Load Address:    0x100773000
    Identifier:      unit
    Version:         ???
    Code Type:       X86-64
    Platform:        macOS
    Parent Process:  leaks [43428]
    Date/Time:       2022-12-22 16:06:03.144 -0500
    Launch Time:     2022-12-22 16:05:52.450 -0500
    OS Version:      macOS 11.7.1 (20G918)
    Report Version:  7
    Analysis Tool:   /Applications/
    Analysis Tool Version:  Xcode 13.2.1 (13C100)
    Physical footprint:         8888K
    Physical footprint (peak):  8932K
    leaks Report Version: 4.0
    Process 43429: 21566 nodes malloced for 3496 KB
    Process 43429: 21 leaks for 1488 total leaked bytes.
        21 (1.45K) << TOTAL >>
          3 (192 bytes) ROOT LEAK: <NSMenuItem 0x7fcefe518bf0> [112]
             2 (80 bytes) _title --> <CFString 0x7fcefe514590> [48]  length: 9  immutable non-inline Unicode:  "Quit unit"
                1 (32 bytes) <CFString (Storage) 0x7fcefe5136c0> [32]
          3 (192 bytes) ROOT LEAK: <NSMenuItem 0x7fcefe5199c0> [112]
             2 (80 bytes) _title --> <CFString 0x7fcefe504550> [48]  length: 10  immutable non-inline Unicode:  "About unit"
                1 (32 bytes) <CFString (Storage) 0x7fcefe521570> [32]
          3 (192 bytes) ROOT LEAK: <NSMenuItem 0x7fcefe6076f0> [112]
             2 (80 bytes) _title --> <CFString 0x7fcefe60b4b0> [48]  length: 9  immutable non-inline Unicode:  "Quit unit"
                1 (32 bytes) <CFString (Storage) 0x7fcefe604d90> [32]
          3 (192 bytes) ROOT LEAK: <NSMenuItem 0x7fcefe60b0e0> [112]
             2 (80 bytes) _title --> <CFString 0x7fcefe60af00> [48]  length: 10  immutable non-inline Unicode:  "About unit"
                1 (32 bytes) <CFString (Storage) 0x7fcefe60b070> [32]
          3 (192 bytes) ROOT LEAK: <NSMenuItem 0x7fcefe705d20> [112]
             2 (80 bytes) _title --> <CFString 0x7fcefe705c50> [48]  length: 10  immutable non-inline Unicode:  "About unit"
                1 (32 bytes) <CFString (Storage) 0x7fcefe705d00> [32]
          3 (192 bytes) ROOT LEAK: <NSMenuItem 0x7fcefe706740> [112]
             2 (80 bytes) _title --> <CFString 0x7fcefe705ef0> [48]  length: 9  immutable non-inline Unicode:  "Quit unit"
                1 (32 bytes) <CFString (Storage) 0x7fcefe706720> [32]
          1 (112 bytes) ROOT LEAK: <NSMenuItem 0x7fcefe51ac20> [112]
          1 (112 bytes) ROOT LEAK: <NSMenuItem 0x7fcefe60b610> [112]
          1 (112 bytes) ROOT LEAK: <NSMenuItem 0x7fcefe705fd0> [112]

    The leaked strings are easily fixes (see #172) by adding autorelase. Somehow some other references stick around though.

    And I would expect the application to be closable, even with no window. This may not be too interesting of a use case right now, but sure will be moving forward with applications running in the background that can be opened via the system tray or similar.

    opened by szanni 0
  • uiMenu: Fix uiUninit() + cmocka tests + darwin: Remove uiprivMap()

    uiMenu: Fix uiUninit() + cmocka tests + darwin: Remove uiprivMap()

    • Fixes presented in #169 for all platforms pertaining uiMenu re-initialization
    • Cmocka test cases for uiMenu #170
    • Darwin: refactoring removing global state and uiprivMap() #165
    • Darwin: fix memory leak of strings "About unit", "Quit unit"

    The existing memory leak around the NSObjects for About, Preferences and Quit still exists however. Run leaks --atExit -- ./build/meson-out/unit to see what objects remain. Interestingly enough test case triggering the problem is initUninitTwice. I haven't been able to figure out who still holds a reference, I assume it has to do with the mixing of ARC, MRR and @autoreleasepool. But maybe the problem lies somewhere else, as the problem seemingly disappears when creating a window.

    opened by szanni 0
  • Fix uiNewMenu when initializing libui-ng a second time.

    Fix uiNewMenu when initializing libui-ng a second time.

    Reset the global variables on uiprivUninit() for all platforms. This will should allow for re-initializing an application that contains menus.

    From preliminary testing the code seems to work on all platforms. I tested Window7, Linux (gtk 3.24.35), macOS Big Sur. Hope I did not miss something.

    Fixes #169

    Edit: Branch That combines the fixes here with the tests in #170.

    opened by szanni 0
  • unit: Add unit tests for uiMenu

    unit: Add unit tests for uiMenu

    Edit: I must have pressed the wrong PR button. I would still like to add more tests to this. But here you go.

    Add unit tests for uiMenu. Depends on #171

    Edit2: Branch That combines the fixes in #171 with the tests here.

    opened by szanni 0
  • uiNewMenu() fails when called a second time after uiUninit() and uiInit()

    uiNewMenu() fails when called a second time after uiUninit() and uiInit()

    Similar to #118, another uiUninit() followed by uiInit() problem: Any application creating a menu and hence possibly calling uiNewMenu() after a reset (uiUninit(); uiInit();) will refuse to work the second time around.

    You can check it out by running meson test on this branch

    Does anyone know why the menu needs to be finalized in the first place? Why can we not modify the menu after creating the first window? Is this related to a limitation of one of the underlying platforms or just a library quirk?

    opened by szanni 2
This is a collection of widgets and utilities for the immediate mode GUI (imgui) that I am developing for the critic2 GUI

ImGui Goodies This is a collection of widgets and utilities for the immediate mode GUI (imgui) that I am developing for the critic2 GUI. Currently, th

null 95 Nov 19, 2022
A tiny, portable, immediate-mode UI library written in ANSI C

A tiny, portable, immediate-mode UI library written in ANSI C Features Tiny: around 1100 sloc of ANSI C Works within a fixed-sized memory region: no a

null 2.5k Jan 6, 2023
Elements C++ GUI library

Elements C++ GUI library Introduction Elements is a lightweight, fine-grained, resolution independent, modular GUI library. Elements is designed with

Cycfi Research 2.5k Dec 30, 2022
Minimalistic C++/Python GUI library for OpenGL, GLES2/3, Metal, and WebAssembly/WebGL

NanoGUI NanoGUI is a minimalistic cross-platform widget library for OpenGL 3+, GLES 2/3, and Metal. It supports automatic layout generation, stateful

Mitsuba Physically Based Renderer 1.2k Dec 28, 2022
A single-header ANSI C immediate mode cross-platform GUI library

Nuklear This is a minimal-state, immediate-mode graphical user interface toolkit written in ANSI C and licensed under public domain. It was designed a

Immediate Mode UIs, Nuklear, etc. 6.7k Dec 24, 2022
A library for creating native cross-platform GUI apps

Yue A library for creating native cross-platform GUI apps. Getting started Documentations FAQ Development Examples Sample apps (with screenshots) Muba

Yue 2.8k Jan 7, 2023
A barebones single-header GUI library for Win32 and X11.

luigi A barebones single-header GUI library for Win32 and X11. Building example Windows Update luigi_example.c to #define UI_WINDOWS at the top of the

Nakst 235 Dec 30, 2022
✔️The smallest header-only GUI library(4 KLOC) for all platforms

Welcome to GUI-lite The smallest header-only GUI library (4 KLOC) for all platforms. 中文 Lightweight ✂️ Small: 4,000+ lines of C++ code, zero dependenc

null 6.6k Jan 8, 2023
Minimalistic GUI library for OpenGL

NanoGUI NanoGUI is a minimalistic cross-platform widget library for OpenGL 3.x or higher. It supports automatic layout generation, stateful C++11 lamb

Wenzel Jakob 4.2k Jan 1, 2023
raygui is a simple and easy-to-use immediate-mode-gui library.

raygui is a simple and easy-to-use immediate-mode-gui library.

Ray 2k Dec 30, 2022
Cross-platform GUI library

Harbour Nuklear backend This backend provides support for Nuklear. It works on on all supported platforms with an OpenGL backend, including iOS and An

Rafał Jopek 2 Jan 19, 2022
Fishui - CutefishOS GUI library, based on Qt Quick.

FishUI FishUI is a GUI library based on QQC2 (Qt Quick Controls 2), every Cutefish application uses it. Features Light and Dark Mode Borderless window

CutefishOS 200 Dec 30, 2022
Nana is a C++ standard-like GUI library

Nana C++ Library Linux (gcc 8.3.0 and 9.2) including (nana-demos) Windows (Microsoft (R) Build Engine version 15.9.21) Nana is a C++ standard-like GUI

Jinhao 2.1k Jan 3, 2023
Examples, tutorials and applications for the LVGL embedded GUI library

Examples, tutorials and applications for the LVGL embedded GUI library

LVGL 441 Nov 11, 2022
Addon widgets for GUI library Dear ImGui.

ImGui-Addons Addon widgets for GUI library Dear ImGui. File Dialog A simple cross-platform file dialog that uses dirent interface for reading director

null 286 Jan 7, 2023
FlatUI is a immediate mode C++ GUI library for games and graphical applications.

FlatUI is a immediate mode C++ GUI library for games and graphical applications. Go to our landing page to browse our documentation.

Google 610 Dec 23, 2022
HastyBadger is a branch of the excellent widget and GUI library Turbo Badger.

Branch Notice - HastyBadger Hasty is not Turbo. HastyBadger is a branch of the excellent widget and GUI library Turbo Badger. Notabe additions are c++

Michael Tesch 38 Nov 17, 2022
The HorusUI library allows you to quickly develop GUIs for your applications by leveraging the ease of use provided by immediate mode GUI concepts.

Immediate Mode Graphical User Interface for Tools OVERVIEW The HorusUI library allows you to quickly develop GUIs for your applications by leveraging

null 133 Dec 12, 2022
GWork is a skinnable, embeddable GUI library with an extensive control set

GWork is a skinnable, embeddable GUI library with an extensive control set. Control rendering is abstracted, and can be implemented by any application wishing to use the library. Gwork (pronounced "gw-orc") is a fork of the GUI library GWEN. It was forked to fix issues with GWEN and add new features.

Bill Quith 198 Nov 24, 2022