GO — Healthy across the board

• Last commit today
• 11 active contributors
• Distributed ownership (top contributor 44% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Slint is a declarative GUI toolkit that compiles UI definitions written in the .slint markup language into native applications for Rust, C++, JavaScript, and Python. It targets embedded systems, desktops, mobile, and web platforms with a single UI source, shipping as native code with minimal runtime overhead and designed for responsive, resource-constrained environments. Monorepo with clear separation: internal/compiler/ contains the .slint parser and code generator; internal/core/ holds the runtime; internal/backends/ (winit, qt, android-activity, linuxkms) abstracts platform differences; internal/renderers/ (software, skia, femtovg) handle drawing; language bindings live in api/rs/slint, api/cpp/, api/node/, api/python/. Examples and demos populate examples/ and demos/.

Embedded systems engineers and desktop application developers who need to write cross-platform UIs once and deploy to microcontrollers (STM32, Raspberry Pi), desktops (Windows/macOS/Linux), and web; teams where UI designers work in .slint files while backend developers integrate via Rust/C++/Python/JavaScript APIs.

Production-ready and actively maintained. The codebase is substantial (~12M lines across Rust, Slint, TypeScript, C++), has comprehensive CI/CD across 40+ GitHub workflows, and follows semantic versioning (stable 1.x API). Regular releases, multi-platform testing, and a mature tooling ecosystem (Live Preview, Figma plugin, editor integrations for VSCode/Zed) indicate a stable, well-engineered project.

Low-to-moderate risk: the project maintains 1.x API stability and has strong CI/CD coverage, but depends on external renderers (Skia, femtovg) and backends (Qt, Winit, Android Activity) which could introduce platform-specific issues. The monorepo is large with interdependent crates, so breaking changes in core packages can cascade; however, the maintainer organization (SixtyFPS) actively manages this.

Active development across rendering (Skia/WGPU integration), platform support (embedded via linuxkms, Android, UEFI), and language bindings (Node.js, Python). Multiple GitHub workflows run nightly snapshots, scheduled CI, and material design gallery updates. The project regularly publishes npm packages and PyPI distributions, with recent focus on cross-platform asset management and embedded system tooling.

Clone the monorepo, install Rust (managed by .github/actions/setup-rust), and build a demo: git clone https://github.com/slint-ui/slint && cd slint && cargo build --example gallery --release. For web/WASM, use cd examples/gallery && npm install after building. For Python: pip install slint from PyPI.

Daily commands: Desktop: cargo run --example gallery. Web (WASM): Build with wasm-pack, serve via wasm-demo example. Embedded (STM32): requires internal/backends/linuxkms or demos/printerdemo_mcu with cross-compilation. Node.js: npm run dev in api/node/. Python: python -m slint.examples after installing the package.

• Cargo.toml — Workspace root configuration defining all member crates (API bindings, examples, demos) and shared dependencies across Rust, C++, JavaScript, and Python targets.
• CMakeLists.txt — Primary C++ build configuration orchestrating compilation for native desktop and embedded platforms; essential for understanding cross-language toolchain integration.
• .github/workflows/ci.yaml — Master CI/CD pipeline controlling builds, tests, and deployments across all supported language bindings and platforms; defines the quality gate.
• api/cpp/build.rs — Rust build script bridging Slint compiler and C++ FFI generation; critical for understanding how .slint markup becomes compiled bindings.
• README.md — High-level overview of Slint's architecture, design goals (Scalable, Lightweight), and multi-language support strategy.
• .github/actions/setup-rust/action.yaml — Shared GitHub Actions configuration for Rust toolchain setup; demonstrates standardized environment provisioning across all CI workflows.
• CONTRIBUTING.md — Developer guidelines covering code style, testing expectations, and contribution workflow across Rust, C++, and web language bindings.

Add a New Slint Example Application

1. Create a new directory under examples/ with Cargo.toml referencing api/rs/slint crate (examples/[new-example]/Cargo.toml)
2. Write main.rs that calls slint::init_translations!() and slint::include_modules!() (examples/[new-example]/src/main.rs)
3. Create .slint markup file defining the UI structure and event handlers (examples/[new-example]/ui/app.slint)
4. Register new example in root Cargo.toml [workspace] members array (Cargo.toml)
5. Add CI workflow job to build_and_test_reusable.yaml to validate on all platforms (.github/workflows/build_and_test_reusable.yaml)

Add a New Language Binding (e.g., Ruby, Go)

1. Create api/[language]/ directory with language-specific Cargo.toml or build configuration (api/[language]/Cargo.toml)
2. Implement FFI layer using cbindgen (C++) or language-specific FFI libraries (api/[language]/build.rs)
3. Write high-level API wrapper exposing Slint structs and callbacks to the language (api/[language]/src/lib.rs)
4. Add member to Cargo.toml workspace and conditional CI job in ci.yaml (Cargo.toml)
5. Document API surface and provide minimal example in api/[language]/README.md (api/[language]/README.md)

Add Platform-Specific Feature (e.g., iOS, WebGL Renderer)

1. Create feature gate in api/rs/slint/Cargo.toml with conditional dependencies (api/rs/slint/Cargo.toml)
2. Implement platform abstraction in internal crate (e.g., graphics backend) (api/rs/build/src/[platform]_backend.rs)
3. Add platform-specific build flags and linker configuration in CMakeLists.txt (CMakeLists.txt)
4. Create dedicated CI workflow to test feature on target platform (.github/workflows/[platform]_build.yaml)
5. Document platform prerequisites and limitations in api/cpp/README.md or main README.md (README.md)

Contribute a Custom Widget or Style Theme

1. Add widget definition in examples/gallery or create new themed variant (examples/gallery/ui/[widget_name].slint)
2. Implement styling using Slint's CSS-like syntax with property bindings (examples/gallery/ui/[widget_name].slint)
3. Create preview/test Rust component in examples/gallery/src/ to showcase states (examples/gallery/src/[widget_name]_preview.rs)
4. Add documentation comment block in .slint file explaining properties and event handlers (examples/gallery/ui/[widget_name].slint)
5. Submit PR with updates to CONTRIBUTING.md if establishing new style guidelines (CONTRIBUTING.md)

• Rust + Cargo workspace — Type-safe, zero-cost abstractions, and memory safety for the core runtime; workspace structure enables parallel compilation of multiple language bindings.
• CMake + C++ FFI (cbindgen) — Cross-platform native compilation for desktop/embedded; cbindgen automatically generates safe C++ bindings from Rust, reducing manual maintenance.
• .slint declarative markup language — Single-source-of-truth for UI definition; compiled to efficient code rather than interpreted, enabling lightweight embedded deployment.
• Skia / WebGPU graphics backends — Hardware-accelerated rendering with fallback support; Skia proven for mobile (Flutter, Android), WebGPU future-proofs for web/compute shaders.
• Proc-macros (api/rs/macros) — Zero-runtime reflection overhead; compile-time code generation reduces final binary size for embedded targets.

1. Renderers must be selected at compile time via Cargo features (e.g., renderer-skia vs renderer-femtovg); mixing them causes linker errors. 2. The compiler expects .slint files in specific layout; path resolution for imports is relative to the manifest file. 3. Platform backends (Qt, Winit, linuxkms) require native dependencies (Qt libraries, Xlib, Linux kernel headers); .github/actions/install-linux-dependencies lists them. 4. Embedded targets require cross-compilation toolchains; examples/mcu-embassy and demos/printerdemo_mcu show setup. 5. WASM builds must use the wasm-interpreter crate, not the default compiler; see api/wasm-interpreter/.

• Immediate-Mode GUI (IMGUI) with Declarative Syntax — Slint uses immediate-mode rendering principles (redraw on every frame) but exposes a declarative markup language; understanding this hybrid is key to reasoning about performance and state management in Slint apps
• Platform Abstraction via Trait Objects — Slint abstracts OS differences (Windows/macOS/Linux/Android/embedded) through Rust traits in internal/backends/; learning this pattern helps when adding new platform support or debugging platform-specific bugs
• Reactive Data Binding — UI components automatically re-render when bound properties change; this is core to Slint's declarative model and critical for understanding how state flows through .slint files
• Two-Stage Compilation (DSL → Rust → Native) — The .slint file is parsed and transpiled to Rust code by internal/compiler/, which is then compiled to native binaries; understanding this pipeline is essential for debugging build errors and understanding performance characteristics
• FFI (Foreign Function Interface) across Language Bindings — C++, Python, and Node.js bindings communicate with the Rust runtime via FFI; knowing this is crucial when integrating Slint into non-Rust apps or debugging cross-language type mismatches
• Pluggable Renderers (Software, Skia, femtovg) — Different rendering backends trade off quality, performance, and dependencies; choosing the right renderer (via Cargo features) for embedded vs. desktop is a key architectural decision
• Component Tree and Declarative Nesting — Slint's component keyword defines reusable UI units with hierarchy; this is analogous to React components but expressed declaratively; mastering component composition is essential for building scalable Slint UIs

• linebender/druid — Rust-native immediate-mode GUI toolkit; similar data-binding philosophy but more code-centric, less designer-friendly than Slint's declarative approach
• flutter/flutter — Declarative cross-platform UI framework; Slint's closest conceptual peer, but Flutter is heavier, targets mobile/web primarily, and uses Dart; Slint targets embedded and desktops with native code
• tauri-apps/tauri — Lightweight desktop app framework using web technologies (HTML/CSS/JS); Slint and Tauri target similar use cases (small footprint, native feel) but Tauri is web-based while Slint is native-first
• slint-ui/slint-python — Official Python bindings and packaging for Slint; maintained as a companion to the main repo for PyPI distribution
• slint-ui/vscode-slint — Official VS Code extension providing syntax highlighting, live preview, and LSP integration for .slint development; essential IDE tooling for the ecosystem

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive CI workflow for Zed editor plugin

The repo contains a Zed editor plugin at editors/zed/ but there's no dedicated CI workflow in .github/workflows/ to test, lint, or validate it. This is a gap compared to the extensive CI coverage for other integrations (Node, Python, C++). A new workflow would ensure the editor plugin maintains quality across releases.

• [ ] Create .github/workflows/zed_editor.yaml to build and test the editors/zed/ crate
• [ ] Add steps to run 'cargo clippy' and 'cargo test' for the Zed plugin
• [ ] Integrate with existing setup-rust action from .github/actions/setup-rust/
• [ ] Add workflow trigger on changes to editors/zed/** paths using ci_path_filters.yaml patterns
• [ ] Document the workflow in CONTRIBUTING.md if it exists

Add Python API integration tests for async-io example

The examples/async-io/ crate exists but there's no corresponding Python driver test in tests/driver/python/. Given that Slint supports Python bindings (api/python/slint/), adding integration tests would validate that async I/O patterns work correctly across the Python API, especially important for long-running applications.

• [ ] Create tests/driver/python/test_async_io.py to import and test async-io example patterns
• [ ] Reference existing test structure from tests/driver/python/ for consistency
• [ ] Add test cases validating event loop integration, callbacks, and async operations
• [ ] Update python_test_reusable.yaml workflow to include the new test file
• [ ] Ensure tests validate both synchronous and asynchronous code paths

Add missing C++ backend integration tests for linuxkms renderer

The linuxkms backend exists at internal/backends/linuxkms/ but has no dedicated C++ driver tests in tests/driver/cpp/. This is a gap since other backends have test coverage. Adding C++ integration tests would ensure the Linux KMS renderer works correctly with the C++ API, critical for embedded systems support.

• [ ] Create tests/driver/cpp/test_linuxkms_renderer.cpp with basic rendering tests
• [ ] Reference existing cpp driver test patterns in tests/driver/cpp/ for structure
• [ ] Add test cases for framebuffer initialization, basic drawing, and event handling
• [ ] Conditionally compile tests to only run on Linux using CMake or platform guards
• [ ] Update cpp_package.yaml CI workflow to run the new tests when applicable

• Add missing TypeScript type definitions for the Node.js API in api/node/; check tests/driver/nodejs/ for test coverage gaps and align with C++ / Python bindings.
• Expand the embedded examples documentation: examples/mcu-board-support/ and examples/mcu-embassy/ lack inline comments explaining Cargo.toml feature flags and linker script configuration for novice embedded developers.
• Implement missing color space support in the Skia renderer (internal/renderers/skia/); currently only sRGB is fully tested; add wide-gamut (Display P3) and HDR (scRGB) paths with tests in tests/screenshots/.

Failed to generate security analysis.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/slint-ui/slint shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live slint-ui/slint repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/slint-ui/slint.

What it runs against: a local clone of slint-ui/slint — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in slint-ui/slint | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of slint-ui/slint. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/slint-ui/slint.git
#   cd slint
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of slint-ui/slint and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "slint-ui/slint(\\.git)?\\b" \\
  && ok "origin remote is slint-ui/slint" \\
  || miss "origin remote is not slint-ui/slint (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"
test -f ".github/workflows/ci.yaml" \\
  && ok ".github/workflows/ci.yaml" \\
  || miss "missing critical file: .github/workflows/ci.yaml"
test -f "api/cpp/build.rs" \\
  && ok "api/cpp/build.rs" \\
  || miss "missing critical file: api/cpp/build.rs"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/slint-ui/slint"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.