This README is the one indexed from the repository at its latest ref, not from the tag for this version.

UIng

UIng is a Crystal binding for kojix2/libui-ng.

libui-ng uses the native APIs of each platform: Win32 API, Direct2D, and DirectWrite on Windows; Cocoa (AppKit) on macOS; and GTK+ 3.10+ and Pango on Linux/Unix. You get windows, buttons, text boxes, menus, dialogs, drawing areas, and other standard widgets.

📸 Live Documentation: All screenshots in the README are automatically generated by GitHub Actions on every push, ensuring cross-platform compatibility (Linux, Windows, macOS).

Supported Platforms

• macOS: x86_64 (64-bit), ARM64 (Apple Silicon)
• Linux: x86_64 (64-bit), ARM64
• Windows: x86_64 (64-bit, MSVC, MinGW, and UCRT), x86 (32-bit, MSVC only)

Installation

Add the dependency to your shard.yml:

dependencies:
  uing:
    github: kojix2/uing

• The required libui-ng binary is automatically downloaded from kojix2/libui-ng GitHub Releases via postinstall.
• The UIng project is not just a binding; it provides unofficial patched builds of libui-ng for platforms. For more details, see the README.md and commits on the dev branch.

Quick Start

Clone the repository:

git clone https://github.com/kojix2/uing
cd uing

Create the libui directory and download the static library for your platform:

crystal run download.cr

To run the control_gallery example, use the following command:

crystal run examples/gallery/control_gallery.cr

Windows MSVC Setup

For Windows users using MSVC, use Developer Command Prompt or add Windows Kits path:

$env:Path += ";C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64"

Usage

require "uing"

UIng.init

window = UIng::Window.new("Hello World", 300, 200)
window.on_closing do
  UIng.quit
  true
end

button = UIng::Button.new("Click me")
button.on_clicked do
  window.msg_box("Info", "Button clicked!")
end

window.set_child(button)
window.show

UIng.main
UIng.uninit

DSL style

require "uing"

UIng.init do
  UIng::Window.new("Hello World", 300, 200) { |win|
    on_closing { UIng.quit; true }
    set_child {
      UIng::Button.new("Click me") {
        on_clicked {
          win.msg_box("Info", "Button clicked!")
        }
      }
    }
    show
  }

  UIng.main
end

Note: The DSL style is implemented using Crystal's with ... yield syntax internally.

Examples Gallery

This gallery shows screenshots of example on three platforms (Ubuntu, Windows, macOS).
Images are automatically generated and stored in the screenshots branch.

Window

Control

Container Control

Note: Grid Layout does not work as expected on macOS.

Table

Note: The Table API has quirks. For example, you must manually free memory as instructed when the program terminates.

Area

Menu

Dialog

Image (experimental)

Note: Image display is a feature introduced experimentally in a fork of libui-ng. Please be aware that this feature is not present in the original libui-ng.

API Levels

• Almost all basic control functions such as Window, Label, and Button are covered.
• APIs for advanced controls such as Table and Area are also provided. However, these are still under development and there may still be memory management issues.

Memory Management Policy

UIng wraps libui-ng, a C library with explicit ownership rules. Crystal's GC keeps wrapper objects alive, but it does not decide when native widgets are destroyed. Use destroy for controls and free for standalone native resources.

The main rule is simple: a parent control owns its children. Destroying a parent destroys the native children too, and UIng marks the child wrappers as destroyed. Do not call destroy on a child while it still belongs to a parent.

window = UIng::Window.new("App", 400, 300)
box = UIng::Box.new(:vertical)
button = UIng::Button.new("OK")

box.append(button)
window.child = box

window.destroy # also destroys box and button

If you want to reuse a child, detach it first when the container supports it:

box.delete(button) # detaches; button is still alive
other_box.append(button)

Container behavior:

• Window and Group have one child. Assigning a new child detaches the old child without destroying it. Destroying the Window or Group destroys its current child.
• Box, Form, and Tab support delete(index) and delete(child). delete detaches the child; call child.destroy afterwards if you are done with it.
• Grid does not currently expose a delete API. Destroy the whole grid, or build a new grid if you need to remove children.
• Controls with no parent can be destroyed directly with destroy.

Window closing has one special rule. In Window#on_closing, return true to let libui-ng destroy the native window, or false to keep it open. Do not call window.destroy inside that callback.

window.on_closing do
  UIng.quit
  true
end

on_should_quit does not destroy windows for you. If your app exits from there, explicitly destroy any windows you created.

Some non-control resources must be freed manually:

• Table::Model: destroy all Table controls using the model first, then call model.free.
• Image: call image.free when it is no longer needed. ImageView#image= copies or retains what it needs, but table image values borrow the image, so keep the Image alive while the table may display it.
• Table::Selection: selections passed to on_selection_changed are freed automatically after the callback. If you call table.selection manually, free the returned selection when done.

After destroy or free, do not use the wrapper again.

Example cleanup patterns:

# Reuse a child by detaching it first.
left = UIng::Box.new(:vertical)
right = UIng::Box.new(:vertical)
button = UIng::Button.new("Move me")

left.append(button)
left.delete(button)  # button is detached, not destroyed
right.append(button)

# Remove a child permanently.
box = UIng::Box.new(:vertical)
button = UIng::Button.new("Delete me")

box.append(button)
box.delete(button)
button.destroy

# Table models must outlive tables that use them.
handler = UIng::Table::Model::Handler.new
model = UIng::Table::Model.new(handler)
table = UIng::Table.new(model)

# ... use table ...

table.destroy
model.free

# Images can be freed after ImageView receives them.
image = UIng::Image.new(16, 16)
pixels = Bytes.new(16 * 16 * 4, 0_u8)
image.append(pixels.to_unsafe.as(Pointer(Void)), 16, 16, 16 * 4)

image_view = UIng::ImageView.new
image_view.image = image
image.free

Limitations

libui-ng is cross-platform, but comes with some limitations:

1. The original libui-ng does not provide image display functionality. A patch has been applied in this project to add experimental support, which is available in the main branch.

2. The grid layout system is known to be broken on macOS. A patch has been applied to improve the behavior, though it still does not fully match the expected design.

3. Precise widget positioning is not possible. Control placement is intentionally coarse and cannot be specified numerically. This is likely an intentional constraint to ensure consistent behavior across all three platforms.

4. There is no function to delete columns from the table.

Windows Setup

Hide Console Window

MinGW:

crystal build app.cr --link-flags "-mwindows"

MSVC:

crystal build app.cr --link-flags=/SUBSYSTEM:WINDOWS

Packaging Your Application

To learn how to package your UIng-based application for distribution, refer to the md5_checker example.
This example demonstrates a simple way to bundle your Crystal app with the required native libraries, making it easy to share with others.

Development

Purpose

This project aims to provide a small, sustainable foundation for building simple native GUIs.

Our priority is not to keep adding new features, but to keep the library working, stable, and maintainable over the long term. Providing a full-featured GUI library is not the main scope of this project.

UIng::LibUI

• UIng::LibUI is the module for direct C bindings
• Initially, crystal_lib was used to generate low-level bindings 　　- However, it required many manual conversions, such as changing LibC::Int to Bool. Currently, it is better to use AI.
• When adding new UI components, follow the established callback management patterns
• libui libraries are generated using GitHub Actions at kojix2/libui-ng in the pre-build branch.
  • Enhancement patches such as image display functionality are provided on the dev branch.
• comctl32.manifest is embedded in Windows builds so Win32 widgets use Common Controls v6 visual styles instead of the legacy classic appearance.

Memory Safety

UIng applies several strategies to ensure safe interoperation between Crystal’s garbage-collected runtime and native C code:

• Callback Protection: Most callbacks are stored as instance variables of their controls, preventing them from being collected by the GC. Closures are additionally protected using ::Box.box(), allowing Crystal blocks that capture external variables to be safely used as C callbacks.

• Reference Chains: Controls are passed to parent containers (e.g., Window -> Box -> Button), ensuring that children remain referenced as long as the parent exists. Root components such as Window and Menu are stored as class variables to avoid premature collection.

• Extended Handler Structures: For complex controls like Area and Table, extended C structs embed the base handler along with extra fields for boxed callbacks. Static C-compatible trampolines cast back to these extended structs and invoke the stored closures safely.

• Resource Management rules are defined in Memory Management Policy. In short, UIng prioritizes explicit ownership and explicit release (destroy / free), while RAII-style APIs are provided where possible.

Closures in Low-Level Contexts

• Many methods support Crystal closures because the underlying libui-ng functions accept a data parameter.

• In some low-level APIs, such as function pointers assigned to struct members, no data can be passed. UIng works around this by using struct inheritance and boxed data to support closures in these cases.

• This approach is used in controls like Table and Area.

Use of AI Coding

This project was developed with the assistance of generative AI.

In particular, AI was extensively used for:

• Creating GitHub Actions workflows for screenshot automation
• Generating complex example programs
• Producing patches for libui-ng

While kojix2 enjoys code generation and “Vibe Coding,” UIng is not a library created purely with that approach. In reality, it was built through substantial manual work, iterative design, and human review of AI-generated code.

I also maintain several projects that are based purely on the Vibe Coding style, but I do not consider this library to be one of them.

Contributing

• Fork this repository
• Report bugs and submit pull requests
• Improve documentation
• Test memory safety improvements

License

MIT License