[Feat]: Explore a native GPUI desktop shell on top of the Rust application core

Start by reading the architecture split in src-tauri/src/application/ and transport/desktop/, then review the design tokens in packages/web-ui and the constraints described in the linked Tauri post. This issue asks for an RFC and a time-boxed spike covering a connection list and a virtualized result grid; done means maintainers record a yes, later, or no decision and, if exploring, document the spike comparison.

Prerequisites

• I have written a descriptive issue title.
• I have searched existing issues and open pull requests to avoid duplicating an existing feature request. Nothing currently tracks a GPUI / native-Rust UI path.

🚀 Feature Proposal

Treat a native GPUI desktop shell as a first-class long-term option for Tabularis, and start with a spike / RFC rather than a rewrite.

Today the product is already a Rust systems program (src-tauri/src/application/) with a React 19 + Tailwind UI running in a Tauri v2 webview. The proposal is to keep that application core, and explore rendering the desktop workspace — chrome, explorer, SQL editor, data grid, notebooks, visual EXPLAIN, settings — with GPUI instead of the webview.

GPUI is the GPU-accelerated, hybrid immediate/retained UI used by Zed. A practical component layer already exists in GPUI Kit: virtualized tables, a Tree-sitter code editor, dock/split/tab layout, themes, AccessKit, and Lucide icons. Adjacent data tools such as Zedis already ship a GPUI client in this product category.

This is not “three native UIs” (AppKit / WinUI / GTK). It is one Rust UI on macOS, Windows and Linux, talking to the existing application layer without JSON-serializing every result page across Tauri IPC.

Suggested shape:

1. Keep application/ as the product. Drivers, tunnels, plugins (JSON-RPC over stdio), MCP, keyring, exports stay where they are.
2. Keep the current React/Tauri UI as the production desktop (and web) surface until a GPUI shell is actually better.
3. Spike a second desktop transport that renders a small slice of the workspace in GPUI (connection list + one result grid is enough).
4. Port the design system, not a new product look. Map the tokens and primitives from #195 onto GPUI themes so a native shell still looks like Tabularis.
5. Only then decide whether GPUI becomes the default desktop UI, an optional “native” build, or a closed experiment.

Motivation

Andrea already wrote the argument in Why I chose Tauri, and what it cost me:

A database client is a systems program with a UI problem, not a web app with a database problem.

That post also names the bill:

• Three webviews. WKWebView, WebKitGTK and WebView2 disagree about CSS, input and GPU compositing. Linux reports such as #9, #45, #54, #423 are the webview lottery, not Tabularis logic.
• The IPC tax. A QueryResult of serde_json::Value is serialized into the webview before React can paint the grid. Paging to 500 rows and streaming exports on the Rust side exist because of that fence.
• Native was rejected because it meant three interfaces. GPUI changes that comparison. It is one cross-platform GPU UI in the same language as the core, not Sequel Ace × 3.

A native GPUI shell would also line up with work already happening on the core:

• Query results, grid edits and EXPLAIN graphs could stay as Rust types and be rendered in-process.
• The design-system work in #195 becomes a theme + primitive catalog instead of CSS variables kept in sync by hand across light/dark.
• Contributor plugins stay language-agnostic (stdio JSON-RPC). Only the host UI changes.
• Web / managed mode (#224, #1273) can keep the React UI. GPUI is a desktop renderer, not a replacement for the Axum transport.

I am not asking to freeze feature work or to throw away Monaco, XYFlow and the current contributor loop. I am asking whether the seams in the Tauri post are now expensive enough to justify a time-boxed native spike, now that GPUI + GPUI Kit cover editor, table and dock layouts that did not exist as a realistic option when Tabularis started.

Example

A 200k-row query stays in Rust. The GPUI grid virtual-scrolls the visible window
from the same QueryResult the application layer already owns. No IPC round-trip,
no JSON copies into a webview, no WebKitGTK blank window on that distro.

The window chrome, sidebar, tabs and tokens still read as Tabularis — the same
surfaces, type scale and accent as the current design system — drawn by GPUI.

Web/managed deployments keep serving the existing React UI from the same
application crate.

Hard parts that the spike has to answer honestly:

• SQL editor. Monaco is the current editor. GPUI Kit has a Tree-sitter editor with LSP hooks; Zed has a production editor. Feature parity (multi-cursor, folding, clause-aware autocomplete, notebooks) is the largest port.
• Diagrams. Visual query builder (XYFlow) and visual EXPLAIN are DOM/canvas today. They need a GPUI canvas story, or they stay web-only for a long time.
• GPUI churn. GPUI is still tied to Zed and still pre-1.0. GPUI Kit pins snapshots (gpui-pre-*). A Tabularis shell would need a version policy.
• Contributor pool. Most UI PRs today are TypeScript. A GPUI default UI raises the bar for the people shipping grid/editor polish.
• i18n. 13 locales already exist under packages/web-ui/src/i18n/locales/. A native shell must reuse those catalogs, not fork strings.
• Hybrid escape hatch. tauri-plugin-gpui can render GPUI inside a Tauri window. That may be a smaller first experiment than replacing Tauri’s event loop.

Acceptance criteria

This issue is an RFC. It is done when maintainers can say yes, later, or no with a recorded reason.

• Confirm there is no existing decision that native UI is off the table (the Tauri post argues against three native toolkits; it does not mention GPUI).
• Decide the venue: keep this as a GitHub issue, move it to Discussions, and/or add a line to roadmap.json.
• If the answer is “explore”: publish a short spike brief (goals, non-goals, time box) that reuses src-tauri/src/application/ and does not fork drivers/plugins/MCP.
• Spike scope is small and observable: one window, connection list, run a query, render a virtualized grid from native QueryResult without Tauri IPC.
• Spike records a written comparison on Linux webview bugs, result-grid latency/memory, installer size, editor-gap vs Monaco, and whether web mode still builds (cargo check --no-default-features).
• Design tokens / visual identity from #195 are treated as the source of truth for any GPUI theme. This is a renderer port, not a restyle.
• Current React/Tauri desktop and web transports stay production. No feature freeze. No deletion of packages/web-ui as part of the spike.
• Explicit non-goals for v1 of a native shell: replacing the plugin protocol, rewriting drivers in the UI crate, dropping web/managed mode, matching every Monaco/XYFlow affordance on day one.

Where to start

• Architecture split is already documented: src-tauri/src/application/ is shared; transport/desktop/ is Tauri; web is a separate transport. A GPUI shell should be another transport, not a fork of the core.
• UI that would move: packages/web-ui (workspace chrome, explorer, editor, grid, notebooks, settings) and the visual EXPLAIN package.
• Design source: #195, packages/web-ui theme tokens.
• Constraints already written down: Why I chose Tauri (IPC tax, three webviews, “native meant three UIs”).
• References: GPUI, GPUI Kit (tables, editor, docks), Zedis as a GPUI data client, optional tauri-plugin-gpui hybrid.

Contributor notes

• Follow AGENTS.md and the repository rules.
• Shared backend behavior stays in src-tauri/src/application/ or plain modules. A GPUI experiment belongs in a new desktop transport / crate, not inside Tauri command handlers.
• Preserve cargo check --no-default-features from src-tauri/ so the web transport keeps building.
• Reuse existing locale catalogs; do not hardcode UI strings.
• Map Tabularis design tokens into the GPUI theme. Do not introduce a second visual identity.
• This proposal used an AI assistant for research (repo layout, the Tauri blog post, GPUI/GPUI Kit). I will review any follow-up I submit.
• Questions for maintainers:
  1. Is a GPUI spike interesting, or is the current Tauri/React split the settled architecture?
  2. If interesting, should the first experiment be a standalone GPUI binary against application/, or GPUI hosted inside Tauri?
  3. Should web/managed mode remain the reason the React UI stays indefinitely, even if desktop goes native?

Questions? Ask here or on Discord.