We open-sourced gpui-component, a desktop UI framework built on top of GPUI
We’ve been building gpui-component in the open — a Rust desktop framework used to build Longbridge Pro.
It is built on GPUI and includes 60+ UI components, virtualized data tables and lists, a dock layout system, Markdown and HTML rendering, charts, and a code editor with Tree-sitter and LSP support.
Why we built it
When people talk about desktop UI frameworks, the conversation often focuses on rendering widgets.
In our experience, drawing a button was rarely the difficult part.
The harder part was everything required around it to build an actual information-dense desktop application: focus handling, overlays, large datasets, persistent layouts, draggable panels, text editing, themes, and interactions that remain responsive under load.
We ran into these problems while building Longbridge Pro, a commercial desktop application. Instead of designing a component library in isolation, we gradually extracted and refined the systems we were already using in production.
That work became gpui-component.
It goes beyond a widget library, but it does not try to prescribe an application’s entire architecture. Our goal is to provide the difficult reusable parts while leaving applications room to own their design and structure.
What is included
The project currently includes more than 60 components covering forms, navigation, overlays, feedback, layout, data display, and editing.
A few parts may be especially interesting to developers building larger desktop applications:
- Virtualized data tables with fixed and resizable columns, sorting, cell selection, and support for hundreds of thousands of rows.
- Virtual lists that render only the visible range, including differently sized items.
- A code editor using a rope-backed text model, with Tree-sitter highlighting and LSP diagnostics, completion, and hover.
- A dock system with draggable tabs, nested splits, resizable panels, edge docks, freeform tiles, and serializable layouts.
- Cross-platform support for macOS, Windows, and Linux from one Rust codebase.
The framework is designed around workloads such as 120 FPS interfaces, very large tables, and files around 200K lines. These are the workloads we built and tested around, rather than a promise that every application will reach the same numbers on every machine.
Two layers instead of one
One design decision we made was to separate presentation from reusable behavior.
- gpui-component provides styled components, semantic themes, sizes, and interaction defaults.
- gpui-base provides lower-level behavior and infrastructure for teams that want to build their own visual system.
preview.redd.it
For example, an application can use the finished dock UI directly, or reuse the underlying layout model, drag-and-drop behavior, focus handling, and persistence while rendering the workspace in a completely different style.
The principle we have been working around is:
>Behavior belongs to the foundation. Presentation belongs to the application.
Technical stack
The main pieces are:
- Rust
- GPUI, the GPU-accelerated UI framework developed as part of Zed
- Tree-sitter for syntax highlighting
- LSP integration for editor diagnostics, completion, and hover
- A rope-backed text model for working with large documents
- Serde-compatible state for serializing dock layouts
- WebAssembly for interactive documentation previews
A minimal setup currently looks like this:
1. gpui = { git = "https://github.com/zed-industries/zed" }
2. gpui_platform = { git = "https://github.com/zed-industries/zed", features = ["font-kit"] }
3. gpui-component = { git = "https://github.com/longbridge/gpui-component" }
There are still rough edges, and we would rather hear about them than pretend the framework is finished.Questions, criticism, issues, and small test projects are all welcome.
1 point · 1 comment
Mentions
zed-industries / zed: Code at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter. ★92616 zed-industries/zed
We open-sourced gpui-component, a desktop UI framework built on top of GPUI We’ve been building gpui-component in the open — a Rust desktop framework used to build Longbridge Pro. It is built on GPUI and includes 60+ UI components, virtualized data tables and lists, a dock layout system, Markdown and HTML rendering, charts, and a code editor with Tree-sitter and LSP support. Why we built it When people talk about desktop UI frameworks, the conversation often focuses on rendering widgets. In our experience, drawing a button was rarely the difficult part. The harder part was everything required around it to build an actual information-dense desktop application: focus handling, overlays, large datasets, persistent layouts, draggable panels, text editing, themes, and interactions that remain responsive under load. We ran into these problems while building Longbridge Pro, a commercial desktop application. Instead of designing a component library in isolation, we gradually extracted and refined the systems we were already using in production. That work became gpui-component. It goes beyond a widget library, but it does not try to prescribe an application’s entire architecture. Our goal is to provide the difficult reusable parts while leaving applications room to own their design and structure. What is included The project currently includes more than 60 components covering forms, navigation, overlays, feedback, layout, data display, and editing. A few parts may be especially interesting to developers building larger desktop applications: - Virtualized data tables with fixed and resizable columns, sorting, cell selection, and support for hundreds of thousands of rows. - Virtual lists that render only the visible range, including differently sized items. - A code editor using a rope-backed text model, with Tree-sitter highlighting and LSP diagnostics, completion, and hover. - A dock system with draggable tabs, nested splits, resizable panels, edge docks, freeform tiles, and serializable layouts. - Cross-platform support for macOS, Windows, and Linux from one Rust codebase. The framework is designed around workloads such as 120 FPS interfaces, very large tables, and files around 200K lines. These are the workloads we built and tested around, rather than a promise that every application will reach the same numbers on every machine. Two layers instead of one One design decision we made was to separate presentation from reusable behavior. - gpui-component provides styled components, semantic themes, sizes, and interaction defaults. - gpui-base provides lower-level behavior and infrastructure for teams that want to build their own visual system. preview.redd.it For example, an application can use the finished dock UI directly, or reuse the underlying layout model, drag-and-drop behavior, focus handling, and persistence while rendering the workspace in a completely different style. The principle we have been working around is: >Behavior belongs to the foundation. Presentation belongs to the application. Technical stack The main pieces are: - Rust - GPUI, the GPU-accelerated UI framework developed as part of Zed - Tree-sitter for syntax highlighting - LSP integration for editor diagnostics, completion, and hover - A rope-backed text model for working with large documents - Serde-compatible state for serializing dock layouts - WebAssembly for interactive documentation previews A minimal setup currently looks like this: 1. gpui = { git = "https://github.com/zed-industries/zed" } 2. gpui_platform = { git = "https://github.com/zed-industries/zed", features = ["font-kit"] } 3. gpui-component = { git = "https://github.com/longbridge/gpui-component" } There are still rough edges, and we would rather hear about them than pretend the framework is finished.Questions, criticism, issues, and small test projects are all welcome.
you might enjoy learning more about this zed.dev in case it sparks new ideas ACP helps with agent interoperability and helps a lot of IDEs and ADEs integrate all the major harnesses seamlessly zed zed-industries/zed orca github.com/stablyai/orca/tree/main/src/main I haven't looked at the cli implementation but you can get very far with integrating a harness while not invoking the model directly via API
Hm, should work in GPUI, albeit I see recent reports of bugs here and there - zed#63774 - ahonn/gpui-nonactivating-ime-repro Whether it’ll work in my port, depends on: - does it work in kirahowe.github.io - would it work in gpuix-svelte? I’ll know by end of next week.
Want to be able to have Zed Threads resume across restarts like Herdr? Then add some ♥️ on this issue and give it a try! zed#65484
專案檔案與搜尋放一起！Zed 開源程式編輯器｜GitHub 開源快報 #Shorts Zed 開源程式編輯器，介紹專案開啟、檔案／符號／專案搜尋與整合終端；語言／平台／擴充依版本需求。選用 AI 或協作服務另查費用、資料傳送、權限，開源不代表所有服務免費或離線。未安裝編輯器、不開真實專案、不使用 AI 或協作帳號。README 原始碼主要 GPL-3.0-or-later，標示元件 Apache-2.0；API NOASSERTION，不沿用舊 AGPL 分類。AI 圖是原創情境，不是實際 UI。官方：zed.dev 隱私：zed.dev 專案：zed-industries/zed 資料核對：2026-10-14 GitHub API 與專案 README。星數為當日快照。 畫面含 AI 生成的情境示意圖；GitHub 頁面為實際截圖。旁白為 AI 語音。 訂閱「辰星說Github」，每天兩支，用白話認識開源工具。 #Shorts #GitHub #開源
引き続きgpuiでの中国語・日本語・韓国語（CJK）の禁則処理の問題に取り組んでいる（海外のかたによる取り組みのテストや修正をしている）んだけど、絵文字のおかげで、文字の分断を扱うときに共通のテスト対象ができたのはよいことだ。 昔は「その文字（日本語）、自分の環境では表示できないんだけど」という感じだった。 gpui: Use UAX #14 line breaking for text wrapping by timvermeulen · Pull Request #64624 · zed-industries/zed zed#64624
gpui is so good github.com/zed-industries/zed/tree/main/crates/gp…, feels great to go past the tui for random tooling
J (JoinLines) incorrectly strips comment prefix // when first line is code Hey! I ran into a bug with Join Lines in Vim mode when the first line is code rather than a comment. If you’re running into this too, give the issue a thumbs-up! zed#65836
Trying to fix this GPUI clip rounded issue again. This might be a persistent bug in GPUI. gpui-fast#76 zed#65753 t.co