BUI (Blender UI)

BUI is the user interface of Blender, extracted into a standalone, fast, C-first UI library. You get Blender's look and Blender's interactions, scrubbable number fields, drag-toggles, pie menus, the color wheel, Ctrl+Z on any edit and you can drive it three ways:

• tkinter syntax: run existing tkinter programs unchanged, now looking like Blender.
• Qt syntax: write QWidget / QVBoxLayout / clicked.connect code (a common subset today).
• Blender components: a native component library (Panel, NumberSlider, ColorSwatch, TreeView, PieMenu ...).

All three share one C runtime (kit/). Python builds the widget tree and runs your callbacks. Layout, input, drawing and presenting stay in C.

pip install blenderui          # PyPI name (packaging is ready, first release pending)

_{Left: the component library (examples/components_demo.py). Right: an unmodified tkinter program (examples/tk_unchanged_app.py) running on BUI.}

Contents

• Why BUI
• Status
• Install and build
• Quick start
  • tkinter syntax
  • Qt syntax
  • Blender components
• How it works
• Performance
• Roadmap: more languages and platforms
• Packaging
• Documentation
• Repository layout
• Testing
• License

Why BUI

Status

Install and build

From PyPI (once released)

pip install blenderui

import blenderui.tksyntax as tk          # tkinter syntax
from blenderui.components import App     # Blender components
from blenderui.qtsyntax import QWidget   # Qt syntax

blenderui and bui are the same package (blenderui.X is bui.X); the examples below use bui because that's how the source tree is organised. Use blenderui in published code: the bui name on PyPI belongs to an unrelated project. A console script comes with it: blenderui-tk app.py runs a tkinter app on BUI.

From source

Requirements: CMake ≥ 3.20, a C11/C++17 compiler (GCC / MinGW or Clang; MSVC is untested), and Python 3.11+ with development headers.

git clone <this repository> BUI
cd BUI
cmake -S . -B build
cmake --build build
ctest --test-dir build            # C + Python test suites

The Python package lives in bindings/python/bui. Its compiled extension (buipy) stays in the build tree, and import bui finds it there automatically. Put bindings/python on PYTHONPATH and you are done:

export PYTHONPATH=$PWD/bindings/python        # Windows: set PYTHONPATH=%CD%\bindings\python
python examples/components_demo.py

More detail, including environment variables and troubleshooting: docs/getting-started.md.

Quick start

tkinter syntax

Run any tkinter program on BUI without changing it:

python -m bui.tksyntax examples/tk_unchanged_app.py

Or opt in from code, before anything imports tkinter:

import bui.tksyntax
bui.tksyntax.install()          # `import tkinter` now returns BUI's tkinter

import tkinter as tk
from tkinter import ttk, messagebox

root = tk.Tk()
root.title("Hello")
name = tk.StringVar(value="Cube")
ttk.Entry(root, textvariable=name).pack(fill="x", padx=8, pady=8)
ttk.Button(root, text="Greet",
           command=lambda: messagebox.showinfo("Hi", "Hello " + name.get())).pack()
root.mainloop()

Or import it directly, under its own name:

import bui.tksyntax as tk
from bui.tksyntax import ttk

Everything is supported, including ttk, messagebox, filedialog, simpledialog, colorchooser, font and scrolledtext. That covers pack/grid/place, scrollbars, Canvas (tags, create_window, scroll regions), Text (indices, tags, marks, search, undo), Treeview, bindings, variables and traces, after, and window-manager calls. Full guide: docs/tkinter.md.

Qt syntax

from bui.qtsyntax import (QApplication, QWidget, QVBoxLayout, QFormLayout,
                          QLineEdit, QSlider, QPushButton, QLabel)

app = QApplication([])
window = QWidget()
window.setWindowTitle("Qt syntax on BUI")
layout = QVBoxLayout(window)

form = QFormLayout()
name = QLineEdit()
name.setPlaceholderText("type here…")
level = QSlider()
level.setRange(0, 100)
form.addRow("Name:", name)
form.addRow("Level:", level)
layout.addLayout(form)

status = QLabel("Press the button.")
button = QPushButton("Click me")
button.clicked.connect(lambda: status.setText("Hello " + (name.text() or "BUI")))
layout.addWidget(status)
layout.addWidget(button)

window.show()
app.exec()

Supported classes, signals, layouts and the known gaps: docs/qt.md.

Blender components

from bui.components import (App, Panel, NumberSlider, VectorField, EnumRow,
                            Checkbox, ColorSwatch, Button)

App("Object", (420, 520),
    Panel("Transform",
          VectorField("Location", (0.0, 1.25, 0.0)),
          NumberSlider("Scale", 1.0, min=0, max=10, on_change=print)),
    Panel("Shading",
          EnumRow("Mode", ["Solid", "Material", "Rendered"]),
          Checkbox("Shadows", True),
          ColorSwatch("Color", (0.8, 0.3, 0.1, 1.0))),
    Button("Apply", on_click=lambda: print("apply")),
).run()

Component reference and Blender interaction details: docs/components.md.

How it works

 your code:  tkinter syntax      Qt syntax       bui.components
                  │                 │                  │
                  └──────── Python: options, signals, variables, callbacks
                                    │
 C kit (kit/):  node tree ─ geometry (pack/grid/place) ─ input & interaction
                ─ Blender widget drawing ─ damage-driven raster rendering
                                    │
 window host:   native Win32 window (Windows)   │   stdlib Tk window (elsewhere)

• One node tree. Every widget wraps one kit node: button, number, slider, text, textarea, list, tree, canvas, scrollbar and so on. The C kit owns layout, hit testing, hover, focus, drag grabs, menus, tooltips, undo and animation.
• Tk's geometry managers in C. pack and grid are ports of Tk's own packer and gridder. Qt's box, grid and form layouts are mapped onto them.
• Damage rendering. A state change marks only its widget's rectangle. A frame redraws just those regions into a frame buffer (anti-aliased SDF shapes and a cached native text engine). Only the changed tiles are presented to the window.
• Python stays thin. Facades keep what tkinter and Qt keep in their own scripting layers: option values, variables, traces, signals and bindings.

More: ARCHITECTURE.md.

Performance

Measured on the full component demo (520×900) on a desktop CPU:

The test suite enforces a 120 Hz budget: full frames under 8.3 ms, and interaction frames under 1 ms.

Roadmap: more languages and platforms

BUI's core is plain C with a small, stable surface (kit/include/BUI_kit.h for widgets, api/bui_c_api.h for render sinks). Its output is either a frame buffer (BuiRaster, ARGB pixels plus damage rectangles) or a stream of draw primitives. That makes every target below the same job: bind the C API, feed in input events, and present the pixels or primitives. None of them needs Python.

use blenderui::{App, Panel, NumberSlider, Checkbox, Button};

fn main() {
    App::new("Tool", (360, 260))
        .child(Panel::new("Object")
            .child(NumberSlider::new("Size", 1.0).range(0.0, 10.0)
                .on_change(|v| println!("size = {v}")))
            .child(Checkbox::new("Smooth", true))
            .child(Button::new("Apply").on_click(|| println!("apply"))))
        .run();
}

egui::Window::new("Properties").show(ctx, |ui| {
    blenderui_egui::panel(ui, &mut state.bui_panel);   // a BUI subtree inside egui
});

import { BlenderUI, Panel, NumberSlider, Checkbox } from "@blenderui/react";

export default function Properties() {
  const [size, setSize] = useState(1);
  return (
    <BlenderUI width={360} height={260}>
      <Panel title="Object">
        <NumberSlider label="Size" value={size} min={0} max={10} onChange={setSize} />
        <Checkbox label="Smooth" defaultChecked />
      </Panel>
    </BlenderUI>
  );
}

Work order: the Rust crate first (it also unlocks egui and Bevy), then the WebAssembly build (it unlocks React, JS/TS, Tauri and Electron), then native Linux / macOS windows.

Packaging

The project is packaged as blenderui for PyPI: pyproject.toml with scikit-build-core, which drives the CMake build. One wheel contains the buipy extension plus the bui and blenderui packages.

python -m pip install build
python -m build                     # dist/blenderui-<version>.tar.gz and a wheel

• Version: a single source, bindings/python/bui/_version.py, read by CMake and by the packaging.
• CI: .github/workflows/wheels.yml runs cibuildwheel for CPython 3.11–3.14 on Windows (MinGW), Linux (manylinux) and macOS (arm64 and x86_64), plus an sdist and the full ctest run. Pushing a v* tag publishes to PyPI with trusted publishing (no tokens stored).
• Verified locally: a wheel built on Windows installs into a clean virtualenv and passes the component, syntax, render, tkinter-compat and input suites.
• Release steps and one-time PyPI setup: docs/publishing.md. Changes are recorded in CHANGELOG.md.

Documentation

Examples (examples/):

Repository layout

Testing

ctest --test-dir build --output-on-failure

License

Derived from Blender sources: GPL-2.0-or-later (see LICENSE and the SPDX headers kept in every file).