slint

Expert guidance for building, debugging, and working with Slint GUI applications. Covers the .slint markup language, project setup, debugging with the embedded MCP server, and language API bindings for Rust, C++, JavaScript, and Python.

install
source · Clone the upstream repo
git clone https://github.com/slint-ui/slint
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/slint-ui/slint "$T" && mkdir -p ~/.claude/skills && cp -r "$T/docs/skills/slint" ~/.claude/skills/slint-ui-slint-slint && rm -rf "$T"
manifest: docs/skills/slint/SKILL.md
source content

Slint Development Skill

Use this skill when building, debugging, or reviewing applications that use Slint, a declarative GUI toolkit for native user interfaces across desktop, embedded, mobile, and web platforms.

When to Use This Skill

Use this skill when the task involves:

  • Writing or debugging
    .slint
    files
  • Integrating Slint with Rust, C++, JavaScript, or Python
  • Investigating layout, binding, rendering, or event-handling issues
  • Enabling the Slint MCP server for runtime inspection and UI debugging
  • Explaining or reviewing Slint-specific code patterns

How to Help

When using this skill:

  • Prefer idiomatic Slint patterns over manual UI workarounds
  • Match guidance to the user's language binding and Slint version
  • Watch for common pitfalls such as binding loops, missing layout constraints, and type mismatches
  • Suggest the MCP server when runtime inspection or interaction would make debugging easier
  • Prefer solutions that preserve Slint's declarative and reactive model

The .slint Language

Slint UIs are written in

.slint
markup files. The language is declarative and reactive.

Project Setup

Rust

# Cargo.toml
[dependencies]
slint = "1.x"

[build-dependencies]
slint-build = "1.x"
// build.rs
fn main() {
    slint_build::compile("ui/main.slint").unwrap();
}
// main.rs
slint::include_modules!();

fn main() -> Result<(), slint::PlatformError> {
    let app = MainWindow::new()?;
    // Set up callbacks, models, etc.
    app.run()
}

C++

Use CMake with

FetchContent
or
find_package
:

find_package(Slint)
slint_target_sources(my_app ui/main.slint)

Node.js

const slint = require("slint-ui");
const app = new slint.MainWindow();
app.run();

Python

import slint
# Load .slint files dynamically

Debugging Slint Applications

Common Issues

  1. Binding loops: A property depends on itself through a chain of bindings. The compiler warns about these. Break the cycle by introducing an intermediate property or restructuring.

  2. Elements not visible: Check

    width
    ,
    height
    (may be 0 if not in a layout),
    visible
    ,
    opacity
    , and parent clipping.

  3. Layout sizing: Elements outside layouts need explicit

    width
    /
    height
    . Inside layouts, they get sized automatically. Use
    preferred-width
    ,
    min-width
    ,
    max-width
    to constrain.

  4. Type mismatches:

    length
    and
    int
    /
    float
    are different types. Use
    1px * my_int
    to convert, or
    my_length / 1px
    to get a number.

  5. Performance: Use

    ListView
    (not
    for
    in
    ScrollView
    ) for long lists because it virtualizes. Use
    image-rendering: pixelated
    only when needed. Avoid deeply nested opacity or clip layers.

Debug Helpers

  • debug("message", expression)
    prints to stderr at runtime
  • SLINT_DEBUG_PERFORMANCE=refresh_lazy,console
    enables performance diagnostics
  • Run with
    SLINT_BACKEND=winit-skia
    or other backend variants for testing

MCP Server for AI-Assisted Debugging

Slint includes an embedded MCP (Model Context Protocol) server that lets you inspect and interact with a running Slint application in real time. The server provides tools for exploring the UI tree, taking screenshots, clicking elements, dragging, typing, and more.

Once enabled, an AI coding assistant can connect to the MCP endpoint to inspect and interact with the running UI.

Enabling the MCP Server

Important: The MCP server is exposed through the internal crate

i-slint-backend-selector
, not the public
slint
crate. This internal crate does not follow semver and must be pinned to the exact Slint version using
=
. If the project uses
slint = "1.16.0"
, then the backend selector must use
version = "=1.16.0"
. A version mismatch will cause build failures.

Step 1: Add the

i-slint-backend-selector
crate with the
mcp
feature to the project's
Cargo.toml
, pinned to the exact same version as the
slint
crate:

[dependencies]
slint = "1.16.0"
i-slint-backend-selector = { version = "=1.16.0", features = ["mcp"] }

If the project is part of a workspace that depends on Slint from a path (e.g. working within the Slint repo itself), use the workspace reference instead and enable the feature via

--features i-slint-backend-selector/mcp
on the cargo command line.

Step 2: Build with

SLINT_EMIT_DEBUG_INFO=1
so that element IDs and source locations are preserved in the compiled output. Without this, elements will lack the debug metadata needed for meaningful introspection. Set
SLINT_MCP_PORT
to an available port when running:

SLINT_EMIT_DEBUG_INFO=1 SLINT_MCP_PORT=9315 cargo run -p my-app

Step 3: Connect to the running application's MCP server at

http://localhost:9315/mcp
using Streamable HTTP transport and use the available tools to inspect and interact with the UI.

Version Requirements

The MCP server uses internal Slint APIs (

i-slint-backend-selector
), so the available features depend on the Slint version:

Slint VersionMCP Support
< 1.16.0Not available
>= 1.16.0Full MCP server with
i-slint-backend-selector
mcp
feature

The

i-slint-backend-selector
crate does not follow semver. It must be pinned to the exact Slint version with
=
. MCP features and tools may change between Slint releases without notice.

When to Suggest MCP

Suggest enabling the MCP server when the user is:

  • Debugging layout or visual issues
  • Trying to understand the runtime element hierarchy
  • Testing interactions programmatically
  • Verifying accessibility properties
  • Diagnosing event handling problems

Documentation Reference

Full documentation for the latest version is at https://slint.dev/docs. Key sections:

  • Language guide: concepts, syntax, and coding patterns
  • Reference: elements, properties, types, and standard widgets
  • Language integrations: Rust, C++, Node.js, and Python API docs
  • Tutorials: step-by-step guides for each language

For a specific Slint version, the documentation can be found at

https://releases.slint.dev/<version>/docs
, for example
https://releases.slint.dev/1.15.1/docs
.