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

Related tags

libui
Overview

libui: a portable GUI library for C

This README is being written.
Build Status, Azure Pipelines
Build Status, AppVeyor

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.

See also this and this.

Contributing

See CONTRIBUTING.md.

Screenshots

From examples/controlgallery:

Windows

Unix

OS X

Issues
  • [POLL] Build system change

    [POLL] Build system change

    I had four reasons for choosing flat makefiles:

    1. I wanted libui to not have any extra dependencies (GNU make on Windows was already pushing it, but nmake is just way too primitive).
    2. I wanted to ensure that every generated file goes somewhere clean that I can predict away from the actual source code, in this case to just .obj and out directories (obviating the need for #13 in my opinion, at least)
    3. I'm not really a fan of other build systems to begin with, either because of their complexity or their mess (see point 2 above)
    4. I wanted to know exactly what was going on in the build process

    However it seems that this decision is causing problems for lots of people, mostly on Windows where the command-line Visual Studio tools either behave unpredictably or require special handling depending on the configuration. @kainjow in #15 makes a really good point: most Windows users are likely more familiar with an IDE than with the command-line build system, to the point that command-line systems like cmake are more accessible.

    While it's true I originally resisted changing, thinking make would be simpler, the number of build issues keeps growing, especially on other platforms. So now I'm willing ot hear arguments for specific build systems.

    I genuinely do not have a preference for any one build system over the other, so please make your case for one you prefer. As part of your case, you should demonstrate what a setup for libui, the test/ folder, and each example would look like, as well as (if possible) a rule to build all examples. Feel free to point out any other advantages or disadvantages.

    Here is a page detailing what an ideal build system would be like: https://gist.github.com/andlabs/243d5d817d291fa62722c33a9c58c6ab

    Right now the following are being considered:

    • cmake
    • waf
    • scons

    I'll make my decision and switch build systems if one appeals to me more than the others.

    Thanks for your feedback! I do appreciate it all, and I want to make sure libui works for everyone :)

    enhancement help wanted question 
    opened by andlabs 85
  • Table planning: loose ends

    Table planning: loose ends

    Table views will operate like GtkTreeView or NSTableView: you have a model with columns for raw data and a view with a series of columns, each containing cells that take those model columns and build the final view out of them.

    There are a few things I'm not sure about when it comes to tables that I'll pose as an open question.

    First, should table view and tree view be separate? They are on OS X, are not on GTK+, and might be on Windows.

    Second, how should I permit the layout of each cell of the table? All cells in a column would have the same layout, but I really have two options here:

    • Fixed: you can have ONE checkbox, ONE image, ONE text, ONE progress bar, etc. or any combination of the above (in a fixed order), and one background color for everything in a cell
    • Variable: you can create complex but linear layouts of cell options, each pointing to different columns of your data model; this would be similar to uiBox, but with slightly different mechanics

    The question is really about how much freedom I need to give; it might not affect the implementation on GTK+ or OS X too much, but it will for Windows.

    Third, and speaking of Windows, I'm still not sure if I should just custom-draw a List View or use my own control for this. (I have my own, but I want to redesign it to use the variable cell renderer approach.) If I do take the custom draw approach, I wouldn't know how to handle accessibility...

    opened by andlabs 59
  • Automating binary attachments to release.

    Automating binary attachments to release.

    Hi, I'm trying to automate the process of binaries attachment to GH releases. We previously discussed this stuff on #124.

    I will use these binaries on libui-download to avoid compile libui on each libui-node install.

    This is a work in progress. Just publish the PR to get early feedback from you...

    Some open issues and questions:

    • You can see the actual attached files on this test release. Please suggest improvement or changes to file names as you like.
    • I created many tags on my fork to trigger travis release builds, I don't know if these could be polluting this PR. please double check!
    • The travis yaml file is becoming a mess. I'm thinking of creating a scripts folder to move some commands there... thoughts?
    • Actually, there is no binaries for windows and for linux 32bit. I could try to use docker on travis to get a 32bit env, and to use appveyor for windows build
    • You'll have to change the secure key with one for your repo after merge the PR. The actual one it's for my fork...
    opened by parro-it 55
  • unix: segmentation fault

    unix: segmentation fault

    Thread 1 "main" received signal SIGSEGV, Segmentation fault.
    0x00000000010f40d0 in ?? ()
    (gdb) bt
    #0  0x00000000010f40d0 in ?? ()
    #1  0x00000000007aacae in onConfigure (win=0x1020df0, e=0x10f0ee0, data=0x105b020) at /home/simon/projects/libui/unix/window.c:53
    #2  0x00007ffff721372c in ?? () from /usr/lib/libgtk-3.so.0
    #3  0x00007ffff5973fa5 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
    #4  0x00007ffff5985fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
    #5  0x00007ffff598e6bf in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
    #6  0x00007ffff598efff in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
    #7  0x00007ffff73557bc in ?? () from /usr/lib/libgtk-3.so.0
    #8  0x00007ffff7212784 in gtk_main_do_event () from /usr/lib/libgtk-3.so.0
    #9  0x00007ffff6d49735 in ?? () from /usr/lib/libgdk-3.so.0
    #10 0x00007ffff6d766a2 in ?? () from /usr/lib/libgdk-3.so.0
    #11 0x00007ffff569edd7 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
    #12 0x00007ffff569f040 in ?? () from /usr/lib/libglib-2.0.so.0
    #13 0x00007ffff569f362 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
    #14 0x00007ffff7211a55 in gtk_main () from /usr/lib/libgtk-3.so.0
    #15 0x00000000007a757d in uiMain () at /home/simon/projects/libui/unix/main.c:37
    #16 0x0000000000469630 in runtime.asmcgocall () at /usr/lib/go/src/runtime/asm_amd64.s:582
    #17 0x000000c8200216d8 in ?? ()
    #18 0x000000000041017a in runtime.cgocall (fn=0xdbd100 <runtime.work+192>, arg=0x7fffffffe790, ~r2=14406048) at /usr/lib/go/src/runtime/cgocall.go:110
    #19 0x000000000043df60 in runtime.startTheWorldWithSema () at /usr/lib/go/src/runtime/proc.go:986
    #20 0x0000000000dbd100 in runtime.work ()
    #21 0x00007fffffffe790 in ?? ()
    #22 0x0000000000dbd1a0 in runtime.work ()
    #23 0x000000000043dfd2 in runtime.mstart () at /usr/lib/go/src/runtime/proc.go:1068
    #24 0x0000000000467a68 in runtime.rt0_go () at /usr/lib/go/src/runtime/asm_amd64.s:149
    #25 0x0000000000000001 in ?? ()
    #26 0x00007fffffffe8a8 in ?? ()
    #27 0x0000000000000001 in ?? ()
    #28 0x00007fffffffe8a8 in ?? ()
    #29 0x0000000000000000 in ?? ()
    
    opened by emersion 38
  • Tracking issue for replacing cmake

    Tracking issue for replacing cmake

    cmake has been headache after headache; see https://github.com/andlabs/libui/issues?utf8=%E2%9C%93&q=label%3A%22cmake+dumbness%22+ for a list of particular incidents; there's probably more than this, even

    • [x] Find a replacement
    • [x] Do the replacement
    • [x] Make sure it works with CI

    Requirements, indicating how hard or soft they are:

    • [HARD] Must support both MSVC and MinGW on Windows
    • [HARD] Must support both static and shared library output, on all platforms in all toolkits (except MinGW shared libraries, which libui does not yet support building as)
    • [HARD] Must either support custom .rc files on Windows or provide a supported way of turning them off (even MinGW-w64 has started trying to be "helpful" in a way that makes .exe.manifest files impossible; see this)
    • [MEDIUM-HARD] Must be as easy to configure a build as mkdir build; cd build; tool option=setting option2=setting2 and must be as easy to clean up as rm -rf build
    • [MEDIUM] Must either be explicit about what it's doing or give me a supported way of turning off automatic insertions I don't want
    • [MEDIUM] Should not have any undocumented magic build configurations I don't know about that will break for the one person who tries to use them
    • [MEDIUM] Should not increase the amount of effort required to build libui from source by much; this means being light and generally uncontroversial on dependencies
    • this list is probably incomplete

    Suggested by others for replacement:

    • waf (requires python at runtime)
    • [the winner] meson (requires python and ninja at runtime)

    Other possibilities, in order of decreasing likelihood:

    • a custom thing entirely
    • scons (requires python at runtime)
    • bazel (requires java at runtime)
    • gn (not sure what it depends on at runtime, but there does not seem to be an easily-accessible place for the official one, and lots of forks on github)

    Suggestions from below:

    • buck (basically facebook's version of bazel; requires java at runtime)

    Non-starters:

    • autotools (I'm here to decrease headache, not increase headache)
    opened by andlabs 37
  • windows: could not build on Windows 7

    windows: could not build on Windows 7

    Impossible for me to build (MVSC 2010):

    Microsoft (R) C/C++ Optimizing Compiler Version 18.00.31101 for x86
    Copyright (C) Microsoft Corporation.  All rights reserved.
    
    cl : Command line warning D9024 : unrecognized source file type 'C:\Users\username\AppData\Local\Programs\Git\Fo;.obj\common_areaevents.c.o', object file assum
    ed
    cl : Command line warning D9024 : unrecognized source file type 'C:/', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'D:/', object file assumed
    cl : Command line warning D9024 : unrecognized source file type '_UI_EXTERN=__declspec(dllexport) extern', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/W4', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/wd4100', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/TC', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/bigobj', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/nologo', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/RTC1', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/RTCc', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/RTCs', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/RTCu', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/Zi', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/Fd.obj/common_areaevents.c.o.pdb', object file as
    sumed
    areaevents.c
    Microsoft (R) Incremental Linker Version 12.00.31101.0
    Copyright (C) Microsoft Corporation.  All rights reserved.
    
    /out:common_areaevents.c.exe
    C:\Users\username\AppData\Local\Programs\Git\Fo;.obj\common_areaevents.c.o
    C:/
    areaevents.obj
    D:/
    "_UI_EXTERN=__declspec(dllexport) extern"
    C:/Users/username/AppData/Local/Programs/Git/W4
    C:/Users/username/AppData/Local/Programs/Git/wd4100
    C:/Users/username/AppData/Local/Programs/Git/TC
    C:/Users/username/AppData/Local/Programs/Git/bigobj
    C:/Users/username/AppData/Local/Programs/Git/nologo
    C:/Users/username/AppData/Local/Programs/Git/RTC1
    C:/Users/username/AppData/Local/Programs/Git/RTCc
    C:/Users/username/AppData/Local/Programs/Git/RTCs
    C:/Users/username/AppData/Local/Programs/Git/RTCu
    C:/Users/username/AppData/Local/Programs/Git/Zi
    C:/Users/username/AppData/Local/Programs/Git/Fd.obj/common_areaevents.c.o.pdb
    LINK : fatal error LNK1181: cannot open input file 'C:\Users\username\AppData\Local\Programs\Git\Fo;.obj\common_areaevents.c.o'
    make[1]: *** [.obj/common_areaevents.c.o] Erreur 2
    make: *** [libui] Erreur 2
    
    C:\Users\username\libui-master>make > log
    Microsoft (R) C/C++ Optimizing Compiler Version 18.00.31101 for x86
    Copyright (C) Microsoft Corporation.  All rights reserved.
    
    cl : Command line warning D9024 : unrecognized source file type 'C:\Users\username\AppData\Local\Programs\Git\Fo;.obj\common_areaevents.c.o', object file assum
    ed
    cl : Command line warning D9024 : unrecognized source file type 'C:/', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'D:/', object file assumed
    cl : Command line warning D9024 : unrecognized source file type '_UI_EXTERN=__declspec(dllexport) extern', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/W4', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/wd4100', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/TC', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/bigobj', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/nologo', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/RTC1', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/RTCc', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/RTCs', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/RTCu', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/Zi', object file assumed
    cl : Command line warning D9024 : unrecognized source file type 'C:/Users/username/AppData/Local/Programs/Git/Fd.obj/common_areaevents.c.o.pdb', object file as
    sumed
    make[1]: *** [.obj/common_areaevents.c.o] Erreur 2
    make: *** [libui] Erreur 2
    
    opened by yageek 33
  • Fix uiImage on mac

    Fix uiImage on mac

    • Fix uiImageAppend on macOS (too much memory was allocated and the copying wasn't correct) (not sure if the corresponding linux code is correct)
    =================================================================
    ==21689==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000109017da2 at pc 0x0001090b7a82 bp 0x7ffee6c0ce50 sp 0x7ffee6c0ce48
    READ of size 1 at 0x000109017da2 thread T0
        #0 0x1090b7a81 in uiImageAppend image.m:48
        #1 0x109005635 in appendImageNamed images.c:196
        #2 0x109014ed6 in makePage16 page16.c:110
        #3 0x10900653d in main main.c:162
        #4 0x7fff7e0aa014 in start (libdyld.dylib:x86_64+0x1014)
    
    0x000109017da2 is located 2 bytes to the right of global variable 'dat0' defined in 'libui-table/test/images.c:4:23' (0x1090179a0) of size 1024
    SUMMARY: AddressSanitizer: global-buffer-overflow image.m:48 in uiImageAppend
    
    opened by mischnic 27
  • Webpage Viewer

    Webpage Viewer

    Some kind of webpage component would be nice.

    enhancement 
    opened by PaulBGD 25
  • How to build on windows?

    How to build on windows?

    How can I build this project on windows? Do I use "nmake.exe"? I already took a look at "buildnotes" it says to run "make" but as far as I know theirs no make for windows.

    opened by manvir-singh 24
  • Add uiScrollView GTK implementation

    Add uiScrollView GTK implementation

    This adds a uiScrollView control which implements a scrolling container for a single child control. I have implemented this for the GTK backend. I don't use windows or OS X so I have not implemented this for those platforms, but looking into it it seems like this will be trivial to do on OS X and not too difficult on windows.

    I have tried to keep the interface that uiScrollView exposes consistent with the rest of libui, but let me know if there are any changes that need to be made, I may implement this for the win32 backend if I have time.

    One thing I was not sure about are the signatures in controlsigs.h, I just put the md5 sum of "uiScrollView" as its signature since I could not find any documentation as to what this value should be.

    I've also added a small example program that just shows a bunch of buttons in a scrollable window. Note that the scroll bar is not visible in the screenshot but it's there and works as expected.

    opened by swissChili 0
  • [Feature request] .move() the main window/widget in a cross-platform manner

    [Feature request] .move() the main window/widget in a cross-platform manner

    In the event someone may want to add more features ... :)

    If this is already possible then please excuse the feature request - I looked at https://raw.githubusercontent.com/andlabs/libui/master/unix/window.c at the least but could not find it. Perhaps it is implemented somewhere else, or missing.

    I would like to have the ability to .move() on widgets. I am used to this on ruby-gtk, in particular to position the window on the top left corner of the screen consistently. (I am aware that alternative models exist such as re-opening from the closed position, but I love starting from the top left for my own widgets, so I would like to have this functionality as well.)

    I believe this should work cross-platform since it is basic functionality, but I'd be perfectly happy if it is first added to linux only. :P

    opened by rubyFeedback 0
  • Language agnostic documentation for libui? Tutorial?

    Language agnostic documentation for libui? Tutorial?

    Hey there,

    Go-related documentation is available here:

    https://pkg.go.dev/github.com/andlabs/ui?utm_source=godoc#pkg-constants

    But I was thinking ... since there are language bindings to libui, perhaps we could have a language-agnostic documentation of libui in the long run. Things that should work across the different languages, e. g. setMargin() should be the same all across, so it would have to be documented only once.

    Additionally it would be nice to tie such a documentation to examples, aka make it a bit more like a tutorial.

    opened by rubyFeedback 0
  • fix crt mutex unlock exception on exit

    fix crt mutex unlock exception on exit

    If you configure project with visual studio 2015: meson --buildtype=release --backend=vs2015 --buildtype=debug build Then you can see there is an exception on exit, then reason is same, see http://stackoverflow.com/a/34121629/3408572

    Signed-off-by: atmgnd [email protected]

    opened by atmgnd 0
  • Crashes in example 'test'

    Crashes in example 'test'

    In Page 11-15 -> Page 13 of the test example, clicking delete first when there is nothing more to delete causes the program to crash in a win7, 32-bit operating system.

    Version: alpha4.1

    opened by code2828 0
  • Timer example doesn't compile

    Timer example doesn't compile

    I have no idea what is going on, none of the UI libraries seem to work. I'm stumped, hopefully it's a simple mistake somewhere. Compiling with GCC on cygwin

    /tmp/ccWpqqQP.o:main.c:(.text+0x3c): undefined reference touiMultilineEntryAppend' /tmp/ccWpqqQP.o:main.c:(.text+0x3c): relocation truncated to fit: R_X86_64_PC32 against undefined symbol uiMultilineEntryAppend' /tmp/ccWpqqQP.o:main.c:(.text+0x5c): undefined reference touiQuit' /tmp/ccWpqqQP.o:main.c:(.text+0x5c): relocation truncated to fit: R_X86_64_PC32 against undefined symbol uiQuit' /tmp/ccWpqqQP.o:main.c:(.text+0x90): undefined reference touiMultilineEntryAppend' /tmp/ccWpqqQP.o:main.c:(.text+0x90): relocation truncated to fit: R_X86_64_PC32 against undefined symbol uiMultilineEntryAppend' /tmp/ccWpqqQP.o:main.c:(.text+0xc7): undefined reference touiInit' /tmp/ccWpqqQP.o:main.c:(.text+0xc7): relocation truncated to fit: R_X86_64_PC32 against undefined symbol uiInit' /tmp/ccWpqqQP.o:main.c:(.text+0xee): undefined reference touiNewWindow' /tmp/ccWpqqQP.o:main.c:(.text+0xee): relocation truncated to fit: R_X86_64_PC32 against undefined symbol uiNewWindow' /tmp/ccWpqqQP.o:main.c:(.text+0x103): undefined reference touiWindowSetMargined' /tmp/ccWpqqQP.o:main.c:(.text+0x103): relocation truncated to fit: R_X86_64_PC32 against undefined symbol uiWindowSetMargined' /tmp/ccWpqqQP.o:main.c:(.text+0x108): undefined reference touiNewVerticalBox' /tmp/ccWpqqQP.o:main.c:(.text+0x108): relocation truncated to fit: R_X86_64_PC32 against undefined symbol uiNewVerticalBox' /tmp/ccWpqqQP.o:main.c:(.text+0x11d): undefined reference touiBoxSetPadded' /tmp/ccWpqqQP.o:main.c:(.text+0x11d): relocation truncated to fit: R_X86_64_PC32 against undefined symbol uiBoxSetPadded' /tmp/ccWpqqQP.o:main.c:(.text+0x12d): undefined reference touiWindowSetChild' /tmp/ccWpqqQP.o:main.c:(.text+0x12d): relocation truncated to fit: R_X86_64_PC32 against undefined symbol uiWindowSetChild' /tmp/ccWpqqQP.o:main.c:(.text+0x132): undefined reference touiNewMultilineEntry' /tmp/ccWpqqQP.o:main.c:(.text+0x132): relocation truncated to fit: R_X86_64_PC32 against undefined symbol uiNewMultilineEntry' /tmp/ccWpqqQP.o:main.c:(.text+0x156): undefined reference touiMultilineEntrySetReadOnly' /tmp/ccWpqqQP.o:main.c:(.text+0x156): additional relocation overflows omitted from the output /tmp/ccWpqqQP.o:main.c:(.text+0x162): undefined reference to uiNewButton' /tmp/ccWpqqQP.o:main.c:(.text+0x17f): undefined reference touiButtonOnClicked' /tmp/ccWpqqQP.o:main.c:(.text+0x195): undefined reference to uiBoxAppend' /tmp/ccWpqqQP.o:main.c:(.text+0x1b1): undefined reference touiBoxAppend' /tmp/ccWpqqQP.o:main.c:(.text+0x1c8): undefined reference to uiTimer' /tmp/ccWpqqQP.o:main.c:(.text+0x1e1): undefined reference touiWindowOnClosing' /tmp/ccWpqqQP.o:main.c:(.text+0x1ed): undefined reference to uiControlShow' /tmp/ccWpqqQP.o:main.c:(.text+0x1f2): undefined reference touiMain' collect2: error: ld returned 1 exit status `

    opened by speccius 1
  • uiTable (Windows) read uninitialized pointer

    uiTable (Windows) read uninitialized pointer

    msvc 2019 (64 bits) windows 10 (64 bits)

    uiTable crashs at Windows 10 when access a uninitialized pointer. To reproduce:

    1. populate a uiTable with more than 1000 items
    2. fast scroll with (pgdn)

    Event VM_NOTIFY Stack: libui!uiprivTableModeCellValue+060 libui!drawTextPart+0x16e libui!uiprivTableHandle_NMCUSTOMDRAW+0x1c0 libui!onMY_NOTIFY+0xde libui!runMY_NOTIFY+0xa1 libui!handleParentMessages+0xbb libui!utilWindowWndProc+0x61

    opened by raniervf 0
  • Button style strange in macOS

    Button style strange in macOS

    Hello there,

    I've tried the git version on macOS Big Sur and while most of the controls in the controlgallery look native. The buttons seem to have strange borders like they are missing a very small shadow.

    When you look at a native application (on the right) they do look a bit different than on libui's controlgallery (on the left).

    Screenshot 2021-01-07 at 16 04 51
    opened by markand 0
  • Draw image on uiArea?

    Draw image on uiArea?

    Is there any good and performace effective way of rendering png images inside a uiArea? Looked at the code and dosen't seem to have a dedicated method of drawing an image

    opened by joao678 2
Releases(alpha4.1)
Owner
Pietro Gagliardi
Pietro Gagliardi
Rust bindings to the minimalist, native, cross-platform UI toolkit `libui`

Improved User Interface A cross-platform UI toolkit for Rust based on libui iui: ui-sys: iui is a simple (about 4 kLOC of Rust), small (about 800kb, i

Rust Native UI Group 769 Sep 13, 2021
AccessKit: UI accessibility infrastructure across platforms and programming languages

AccessKit: UI accessibility infrastructure across platforms and programming languages Motivation There are numerous UI toolkits, and new ones continue

null 155 Sep 13, 2021
A data-first Rust-native UI design toolkit.

Druid A data-first Rust-native UI toolkit. Druid is an experimental Rust-native UI toolkit. Its main goal is to offer a polished user experience. Ther

null 4.5k Sep 13, 2021
Rust bindings for Sciter

Rust bindings for Sciter Check this page for other language bindings (Delphi / D / Go / .NET / Python / Rust). Introduction Sciter is an embeddable mu

Terra Informatica Software, Inc 605 Sep 17, 2021
The Rust UI-Toolkit.

The Orbital Widget Toolkit is a cross-platform (G)UI toolkit for building scalable user interfaces with the programming language Rust. It's based on t

Redox OS 3.3k Sep 15, 2021
SixtyFPS is a toolkit to efficiently develop fluid graphical user interfaces for any display: embedded devices and desktop applications. We support multiple programming languages, such as Rust, C++ or JavaScript.

SixtyFPS is a toolkit to efficiently develop fluid graphical user interfaces for any display: embedded devices and desktop applications. We support multiple programming languages, such as Rust, C++ or JavaScript.

SixtyFPS 1.9k Sep 14, 2021
A cross-platform GUI library for Rust focused on simplicity and type-safety

A cross-platform GUI library for Rust, inspired by Elm

Héctor Ramón 11.3k Sep 17, 2021
A cross-platform GUI library for Rust, inspired by Elm

Iced A cross-platform GUI library for Rust focused on simplicity and type-safety. Inspired by Elm. Features Simple, easy-to-use, batteries-included AP

Héctor Ramón 11.3k Sep 13, 2021
A GUI for Cargo

A GUI for Cargo This is a project to make a GUI for cargo, built using SixtyFPS: The idea cargo install cargo-ui cargo ui Prerequisites In addition to

SixtyFPS 31 Sep 14, 2021
A simple UI framework for Rust built on top of IUP (http://webserver2.tecgraf.puc-rio.br/iup/)

KISS-UI A UI framework for Rust based on the KISS (Keep It Simple, Stupid!) philosophy. Powered by the IUP GUI library for C by Tecgraf, via the bindi

null 343 Aug 12, 2021
Rust bindings for the FLTK GUI library.

fltk-rs Rust bindings for the FLTK Graphical User Interface library. The FLTK crate is a crossplatform lightweight gui library which can be statically

Mohammed Alyousef 440 Sep 12, 2021
Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies

Dear ImGui (This library is available under a free and permissive license, but needs financial support to sustain its continued improvements. In addit

omar 31.8k Sep 14, 2021
A tiny, neat C library that portably invokes native file open and save dialogs.

Native File Dialog A tiny, neat C library that portably invokes native file open, folder select and save dialogs. Write dialog code once and have it p

Michael Labbe 1.2k Sep 20, 2021
Rust bindings for Dear ImGui

imgui-rs: Rust bindings for Dear ImGui (Recently under new maintenance, things subject to change) Window::new(im_str!("Hello world")) .size([300.0

null 1.4k Sep 14, 2021
A utility for mapping events from Linux event devices.

What is evsieve? Evsieve (from "event sieve") is a low-level utility that can read events from Linux event devices (evdev) and write them to virtual e

Kars Mulder 44 Sep 14, 2021
Desktop GUI Framework

Azul - Desktop GUI framework WARNING: The features advertised in this README may not work yet. Azul is a free, functional, immediate mode GUI framewor

Maps4Print 4.8k Sep 16, 2021
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. 4.8k Sep 18, 2021
A tiling window manager for Windows

komorebi Tiling Window Management for Windows. About komorebi is a tiling window manager that works as an extension to Microsoft's Desktop Window Mana

Jade (جاد) 177 Sep 11, 2021
A simple, cross-platform GUI automation module for Rust.

AutoPilot AutoPilot is a Rust port of the Python C extension AutoPy, a simple, cross-platform GUI automation library for Python. For more information,

null 196 Sep 17, 2021