LibrePCB GUI Framework: From Qt to Slint in Version 2.0
LibrePCB’s GUI Framework: A Tale of Two Toolkits
LibrePCB ran on Qt from its earliest days around 2013 all the way through version 1.x. Qt handled everything visible — windows, dialogs, widgets, the schematic editor, the board editor — following the classic Qt pattern of one floating window per tool. For a cross-platform C++ EDA application, Qt was a sensible pick: mature, well-documented, and capable of rendering the kind of custom graphics PCB tools need.
What Qt Brought to the Table
Qt is far more than a widget library. LibrePCB leaned on it for file I/O, threading, geometry primitives, and network calls as much as for the visible interface. That depth is exactly why the project never planned to rip Qt out entirely — even after switching UI frameworks, the core business logic stays tied to Qt.
The multi-window model worked, but it had friction. Switching between the schematic editor, board editor, and library manager meant juggling separate windows on screen. Modal dialogs interrupted flow constantly. Veteran users learned to live with it; newcomers found it disorienting.
Version 2.0 and the Switch to Slint
LibrePCB 2.0, released in early 2026, rebuilt the interface from scratch using Slint. Slint is a declarative GUI framework written in Rust that exposes a C++ API — which made it accessible to the LibrePCB team without requiring a full language rewrite. Its UI descriptions are compiled at build time rather than interpreted at runtime, and it ships with a live preview tool that makes iterating on layouts fast.
The result is a single unified window where every document — footprint, schematic, board — opens as a tab. No more hunting across the taskbar for the right editor.
Why Slint Specifically?
A few things made Slint a good fit. First, the C++ API meant the team could keep the existing application logic intact and just replace the presentation layer. Second, Slint’s declarative syntax separates layout from logic cleanly, which helps when you’re redesigning years of accumulated UI code. Third, the framework is actively developed with desktop applications as a first-class target — not just embedded systems, though it supports those too.
The Migration Isn’t Finished
LibrePCB is large enough that a complete cutover in one release wasn’t realistic. In 2.0, the main application shell — the single window, the tab system, the primary panels — runs on Slint. Older dialogs and wizards still run on Qt underneath. Both frameworks link against the same Qt library in this hybrid state, which lets the team ship incremental improvements without holding back the release.
The roadmap calls for converting the remaining Qt dialogs to Slint progressively in subsequent minor releases.
Qt Isn’t Going Away
It’s worth being specific here: Qt is not being removed. The rendering pipeline for schematics and boards, the file abstractions, and a large slice of the application’s utility code all depend on Qt directly. What changed is the widget layer — the visible controls and layout containers. Qt’s non-UI modules stay in place indefinitely.
So the accurate answer to “what framework does LibrePCB use” is: Qt for the core, Slint for the modern interface layer starting with 2.0.
Sources