BookOS apps are changing on the inside: instead of being drawn by a web engine, they are now drawn directly on the GPU with GPUI, in Rust. Here is the whole story: why we are making the move, what GPUI is, what already works, how it is built, what the numbers say, the full roadmap and what it means for you. --- ## In short | | What it means | |:--|:--| | **What changes** | Apps move from Tauri (Rust + HTML, CSS and JavaScript in WebKitGTK) to GPUI (all Rust, rendered on the GPU) | | **What is ready** | Explorer 0.7 and Fonts 0.1. Explorer is also the file picker for the whole system | | **What comes next** | A shared component foundation, `bookos-ui`, followed by the remaining apps in four phases | | **What stays the same** | Apps update through the BookOS Store and your settings stay where they are | | **What we do not know yet** | How much startup, memory and battery improve. We are measuring it | > [!TIP] > **In short:** Tauri gave us speed to create. GPUI gives us speed to use. --- ## Where we come from Over the past year, BookOS has built its own set of applications. Almost all of them share the same recipe: **Tauri 2**. | Area | Apps | |:-----|:-----| | System | Settings, Shell, System Monitor, Remap, BookOS Link | | Files | Explorer, Fonts | | Productivity | Notepad, Calculator, Calendar, Clock, Lumina | | Multimedia | Player, Viewer, Voice Recorder, Camera, Sound Effects | | Store | BookOS Store | A Tauri app has two halves: - The **logic** (reading folders, copying files, talking to the system) is written in **Rust**. - The **interface** is a small web page in **HTML, CSS and JavaScript**, displayed by **WebKitGTK**, GNOME's web engine. - The two halves talk over **IPC**: the interface asks for something and Rust replies with a **JSON** message. That recipe gave us something very valuable: **speed to build**. CSS makes layout quick, the BookOS design system tokens (colours, radii, shadows, animations) mapped directly onto CSS variables, and a single person could put together a complete app in days. > Tauri helped us build quickly. GPUI lets us work on the experience of using those apps. --- ## Why we are changing Tauri was the right tool for building. For polishing, it has four costs that cannot be optimised away from the inside. ### One web engine per window WebKitGTK is installed only once on disk, but **each window starts its own engine**: its own JavaScript interpreter, its own layout engine and its own helper processes. For a calculator, that is a lot of engine for very little calculator. | Where it shows | Why | |:--|:--| | **Startup** | Before you see anything, the window starts the web engine and loads the page | | **Memory** | Every open window adds its own engine | | **Feel** | An app that paints an empty background first does not feel like part of the system | ### Two worlds talking through messages Interface and logic live in different languages. Every piece of data the interface wants to show (a folder with 20,000 files, for instance) is converted to JSON in Rust, sent across and parsed again in JavaScript. And every rule in the app exists twice, once in each language, with no compiler checking that they match. ### Far from the desktop BookOS has its own desktop, **`bookos-desktop`**: a Wayland compositor written in Rust that draws the panel, the dock and the Launchpad. A Tauri app reaches it through GTK and WebKit, with two layers in between. ### Components copied, not shared Common styles and scripts were copied from app to app. A fix in one had to be repeated in all of them, and over time the copies drifted apart. > [!NOTE] > None of this is a flaw in Tauri. It is the normal price of putting a browser inside every app, and it was worth paying to build quickly. --- ## What GPUI is GPUI is the interface framework born inside the **Zed** editor. It is written in Rust and paints every frame on the GPU, with no browser in between. | | Before (Tauri) | Now (GPUI) | |:--|:--|:--| | Logic | Rust | Rust | | Bridge | IPC with JSON | Direct call | | Interface | HTML + CSS + JS | Declarative Rust views | | Rendering | WebKitGTK | GPU (wgpu on Vulkan) | | Windows | Wayland | Wayland + layer-shell | | Components | Copied into each app | Shared `bookos-ui` library | What changes: - **One language.** Logic and interface in Rust: no JSON bridge between two worlds, no state that drifts out of sync. - **No web engine per window.** No WebKit loading inside every app. - **Lists that weigh nothing.** GPUI only builds the rows you can see: a folder with thousands of files costs the same as one with ten. - **Native Wayland**, including layer-shell, the protocol for desktop panels and overlays. - **Direct integration with the desktop**: long copies in Explorer already show up in the BookOS **activity island**, with a "Cancel" button. ### Why GPUI and not something else | Option | For | Against, in our case | |:--|:--|:--| | **Stay on Tauri** | Already works; CSS layout is fast | Keeps the per-window web engine and the JSON bridge | | **GTK 4** | Mature, accessible, integrated with Linux | GTK dictates the look; reproducing the BookOS design means fighting its theme | | **Qt / QML** | Mature, GPU accelerated | The interface is written in QML and C++: another language boundary | | **iced** | Rust; already used by `bookos-desktop` | On the desktop it renders on the CPU; for apps with long lists and images we prefer the GPU and proven virtual lists | | **GPUI** | Rust, GPU, proven in a large app like Zed, CSS-like styling | Not yet at 1.0; no built-in text field and no accessibility on Linux out of the box | > [!NOTE] > We use **our own copy of GPUI**, based on the Glass-HQ fork (commit `650aab5`). That fork stopped building on Linux in March 2026, so we fixed it with a patch of our own that also adds layer-shell. We keep it inside the repository: **an outside update does not reach your laptop until we have tested it.** --- ## What already works ###  Explorer · 0.7 The first major app rewritten in GPUI, and the one that paved the way for all the others. | Feature | What it does | |:--|:--| | Places | Personal folders, mounted drives and recent files in the sidebar | | Thumbnails | Images and PDF pages, scaled to the cell size before they reach the GPU | | Quick Look | With a Markdown preview written from scratch | | Files | Copy, move, rename, trash and properties | | Folder colours | As in the previous version | | Open with… | The right app for each file type | | Activity island | Progress for long copies, with "Cancel" | | File picker | The open and save dialog for **every** BookOS app | ###  Fonts · 0.1 A new app, born directly in GPUI: preview, install and manage typefaces. It reads fonts with `ttf-parser`, which already came with GPUI, so it adds no weight. ### The shared foundation: `bookos-ui` Everything Explorer had to solve for the first time has been extracted into a library that every app shares. A fix there reaches all of them on the next build. | Piece | What it solves | |:--|:--| | Theme | Light, dark and automatic, with the dynamic colour Settings takes from your wallpaper | | Window | Title bar, buttons, corners and resize edges | | Sidebar | The one from Settings, with search, collapsible | | Controls | Switch, slider, drop-down, segmented control and buttons | | Text field | GPUI ships none: this is the one we built for Explorer | | Menu and toasts | Context menu and notices that dismiss themselves | | State | Saved in `~/.config/<app>/`, the same place as the Tauri versions | | Icons | Bundled inside the program | ```chart type: bars title: Rust code written for GPUI unit: lines Explorer: 11397 Fonts: 3884 bookos-ui: 2206 ``` --- ## How it is built For anyone who wants the technical detail. ### Our copy of GPUI GPUI has not reached 1.0 yet and often changes in incompatible ways. Our patch on top of the Glass-HQ fork touches four files: - `crates/gpui/src/platform/layer_shell.rs` - `crates/gpui_linux/src/linux/platform.rs` - `crates/gpui_linux/Cargo.toml` - `crates/gpui_wgpu/src/cosmic_text_system.rs` Every app points to **the same copy, by path**. This is not a preference: if two parts of a program link different copies of GPUI, it does not build. GPUI is built without its default features, with only Wayland and `font-kit`, and no X11. Release builds use full link-time optimisation (LTO), a single code unit and no debug symbols. ### Desktop integration | Piece | How it works | |:--|:--| | **File picker** | The BookOS design system says the file picker is always Explorer. The GPUI version honours that contract: open, save, choose folder, multiple selection, type filters and a configurable title | | **Activity island** | Long copies are published to the island over D-Bus (`org.bookos.Desktop`), with progress every 500 ms and a cancel action | | **Dynamic colour** | Read from `~/.config/bookos/palette.json`, the same source as the rest of the system, and reloaded when you return to the window | ### Memory lives on the GPU What weighs most in a GPUI app is not the code but what is uploaded to the graphics card: text glyphs, images and Vulkan itself. That gives us the rules every app follows: 1. **Icons at the size they are drawn.** GPUI rasterises an SVG at the size the file declares. An icon that declares 504 px takes about 1 MB even if it is drawn at 24. 2. **Images scaled down before upload.** Explorer thumbnails are decoded in the background and scaled to the exact cell size. A 4000×3000 original is freed right away and never reaches the GPU in full. 3. **Virtual lists.** Long lists only build the visible rows. 4. **No object per row.** Data lives in a plain list and the view paints only what is visible. 5. **Minimal dependencies.** If GPUI already ships a library, such as `ttf-parser` or `image`, it is reused. > [!TIP] > **The golden rule:** nothing goes up to the GPU larger than it will be drawn. --- ## Let's be honest about the numbers GPUI is not magic, and we would rather say so. ```chart type: bars title: Installed size of each app unit: MB Explorer Tauri 0.6.2: 6.1 Explorer GPUI 0.7: 26.2 Fonts GPUI 0.1: 16.8 ``` > [!WARNING] > **The program is bigger**, but the comparison is misleading. A Tauri app looks small because it relies on WebKitGTK, which lives separately on the system. GPUI carries everything inside. This is what sits behind the Tauri Explorer's 6.1 MB: ```chart type: bars title: What a Tauri app needs to run unit: MB Explorer Tauri: 6.1 WebKitGTK 4.1: 100.3 JavaScriptCore: 35.3 ``` Those 135 MB of WebKitGTK and its JavaScript engine are shared by every Tauri app, so they cannot be charged in full to any single one either. That is why size on disk **does not tell you which one uses more**. And as long as a single Tauri app remains, WebKitGTK has to stay installed. ### What we are going to measure We will compare the Tauri and GPUI versions of the same app on a Galaxy Book5 Pro running BookOS 0.7, with the balanced power profile, no network and no other apps open: | Measurement | How | Runs | |:--|:--|:--| | **Cold start** | From launch to the first frame with content, with an empty cache | 20 | | **Warm start** | The same, without emptying the cache | 20 | | **Memory** | Sum of all the app's processes, idle and with a folder of 10,000 files | 10 | | **Battery** | Drain over 30 minutes with a fixed usage script | 3 | > [!IMPORTANT] > **We will publish the figures once they are reliable, not before**: the median of each measurement, the usage script and the raw data. And we will publish them even if some do not come out in our favour. --- ## Roadmap ```roadmap title: The path to a native ecosystem - [x] Explorer and Fonts | Completed | Versions 0.7 and 0.1 · GPUI interfaces and a native file picker - [>] Shared foundation | In progress | Themes, typography, icons, text inputs and components for every app - [ ] Everyday apps | Planned | Calculator, Clock and Notepad · Simple logic, daily use - [ ] Multimedia | Planned | Viewer, Player and Recorder · Interfaces rendered directly on the GPU - [ ] Core system | Planned | Settings and BookOS Store · A careful migration of the most complex apps ``` Three rules for reading it: - **Phases, not dates.** Each app takes as long as it takes to match its previous version. We will announce on the blog when each phase closes. - **The order may change** if the community asks for it or if an app turns out simpler than expected. - **No app moves to GPUI** until its new version does everything the previous one did. ### Why this order 1. First, an app that **forces us to solve every new problem**. Explorer had it all: huge lists, images, text, menus and dialogs. 2. Then, **extracting those solutions into a shared library**, so we never solve them twice. 3. Next, **simple, heavily used** apps, where the improvement shows right away and the risk is low. 4. Later, **multimedia**, which needs pieces of its own: audio, large images and system media controls. 5. Finally, **Settings and the Store**: the most complex apps, and the ones that would do the most damage if they failed. ```chart type: donut title: Apps by phase Already on GPUI: 2 Everyday: 3 Multimedia: 3 Core system: 2 No phase yet: 8 ``` ### Phase 1 · Explorer and Fonts — completed Prove that a large BookOS app can live on GPUI without losing features. What we learned: GPUI ships no text field and we had to write one; memory lives on the GPU, not in the code; and the fork did not build on Linux, so we patched it and pinned the version. **What you notice:** the new Explorer, and that the open and save dialog in every other app is Explorer itself. ### Phase 2 · Shared foundation — in progress Make migrating an app mostly a matter of writing its logic, not rebuilding buttons. Theme, window, sidebar, controls, text field, menu, toasts, state and icons are already there. Still to do: - Explorer and Fonts using `bookos-ui` instead of their own copies. - Common dialogs: confirm and report an error. - An accessibility plan. **It closes when** a test app built only with `bookos-ui` passes the design system checklist in light and dark themes. ### Phase 3 · Everyday apps — planned | Apps | Why now | Challenges | |:--|:--|:--| | Calculator, Clock, Notepad | Simple logic, heavy use: faster startup shows right away | A multi-line editor for Notepad; reliable alarms and timers for Clock | **It closes when** all three match their Tauri versions and we have published their startup and memory measurements. ### Phase 4 · Multimedia — planned | Apps | Why now | Challenges | |:--|:--|:--| | Viewer, Player, Voice Recorder | This is where the GPU pays off most: large images, album art, waveforms | Large images without blowing up memory, system media controls (MPRIS) and recording without dropouts | **It closes when** they match their Tauri versions on the formats they already supported and power draw during playback is no worse. ### Phase 5 · Core system — planned | Apps | Why last | Challenges | |:--|:--|:--| | Settings, BookOS Store | Settings touches networking, Bluetooth, display, sound and the colour of the whole system. The Store installs and updates everything else | Many screens, deep integration and no margin for a failed update | > [!CAUTION] > **Settings cannot leave out people who use a screen reader.** This phase does not start until accessibility is solved or has a clear plan. **It closes when** Settings and the Store match their Tauri versions, go through a testing period open to the community, and the Store has successfully updated itself on GPUI. ### Apps without a phase yet They stay on Tauri and will get a phase once the shared foundation is closed. In the meantime, they keep receiving fixes as usual. | Area | Apps | |:--|:--| | System | Shell, System Monitor, Remap, BookOS Link | | Productivity | Calendar, Lumina | | Multimedia | Camera, Sound Effects | > [!IMPORTANT] > **No rush and no cuts:** every app stays on Tauri until its GPUI version matches it. You will never lose features because of the change. --- ## What it means ### For you, as a BookOS user - Apps that **appear sooner** and respond without stutters: that is the goal, and we will confirm it by measuring before we claim it. - **The same look** across the system: same colours, radii, typography and animations. - **Deeper desktop integration**: activity island, a shared file picker and dynamic colours. - **Updates as usual**, through the **BookOS Store**. - **Your data stays where it was**: GPUI versions read their configuration from the same paths. ### What you may notice during the transition | What | Why | |:--|:--| | Small differences between apps | Tauri apps and GPUI apps will coexist for a while | | Rough edges in a freshly migrated app | It is new code, even if it matches the old one feature for feature | | Bigger packages | The rendering engine ships inside each program | ### For people who build BookOS - **One language.** No separate frontend and no IPC commands to keep in sync. - **We have to build what the browser gave us for free**: text fields, menus, scrolling, selection. It is done once, in `bookos-ui`. - **Longer builds**, in exchange for the compiler catching many bugs before anything runs. - There is a **template** with a minimal app that uses every component, ready to copy. --- ## Risks and how we handle them | Risk | What we do | |:-----|:-----------| | GPUI has not reached 1.0 and its fork may change or be abandoned | Our own copy in the repository; we update only when we choose to, and after testing | | Losing features in the rewrite | No app switches until it matches the previous one | | Accessibility: our GPUI copy does not yet expose the interface to screen readers on Linux | Explicit pending work, and a prerequisite before migrating Settings and the Store | | Larger programs on disk | We explain it in context and measure what matters: memory, startup and battery | | Machines without Vulkan | GPUI renders with Vulkan; BookOS is designed for the Galaxy Book, which supports it | > [!CAUTION] > **Accessibility is the most serious debt in this change.** WebKitGTK does expose the interface to screen readers. We will not migrate the core system apps without solving it first. --- ## Frequently asked questions ### Do I need to do anything? No. New versions arrive through the BookOS Store like any other update. ### Will I lose my settings or data? No. GPUI versions save their state in the same folder (`~/.config/<app>/`) as the Tauri versions. ### Why is the new Explorer bigger? Because it carries its rendering engine inside. The previous version needed one too, but borrowed it from WebKitGTK, installed separately. ### Will WebKitGTK disappear from the system? Not while a single Tauri app remains. Once every phase is complete, we will check whether any other part of BookOS still needs it before deciding anything. ### Are there dates? Not yet. We would rather not promise dates we would later have to move. We will announce on the blog when each phase closes. ### Will it work on my machine if it is not a Galaxy Book? GPUI needs a graphics card with Vulkan. BookOS is designed and tested for the Galaxy Book; other machines with Vulkan should work, but they are not our target today. --- ## Get involved If you want to try the GPUI versions before anyone else or tell us which app should go first, stop by the [community](/community.html). And if something goes wrong, let us know: it is the fastest way to get it right for everyone. **The future of BookOS is written in Rust. And it is painted on the GPU.** --- ## References - Zed Industries. *GPUI*, the interface framework of the Zed editor. [github.com/zed-industries/zed](https://github.com/zed-industries/zed) - Glass-HQ. *Standalone fork of GPUI*, commit `650aab5`. - *Tauri 2*. [tauri.app](https://tauri.app) - *WebKitGTK*. [webkitgtk.org](https://webkitgtk.org) - *wgpu*. [wgpu.rs](https://wgpu.rs) - *Smithay*, the library `bookos-desktop` is built on. [github.com/Smithay/smithay](https://github.com/Smithay/smithay) - *wlr-layer-shell*, the desktop surface protocol. [wayland.app/protocols/wlr-layer-shell-unstable-v1](https://wayland.app/protocols/wlr-layer-shell-unstable-v1)