97 lines
4.2 KiB
Markdown
97 lines
4.2 KiB
Markdown
# Native UI decision
|
|
|
|
Lumbridge will not use Electron, React, TypeScript, or a webview as its
|
|
application shell. The shell, layout engine, terminal, session runtime, and
|
|
editor surfaces must be native Rust. An isolated browser pane may host the
|
|
operating system web engine because rendering arbitrary web pages is a browser
|
|
problem, not an application-shell architecture.
|
|
|
|
This decision stays open until the finalists run the same workload. Choosing on
|
|
repository popularity or a polished demo would hide the risks that matter for a
|
|
terminal-heavy, accessibility-aware, cross-platform IDE.
|
|
|
|
## Finalists
|
|
|
|
### GPUI
|
|
|
|
GPUI is the closest architectural match to Zed: retained state, GPU rendering,
|
|
text-heavy native interfaces, and an Apache-2.0 framework crate. It is the
|
|
highest-upside choice if Lumbridge wants Zed-like responsiveness and is willing
|
|
to track a fast-moving framework.
|
|
|
|
Risks:
|
|
|
|
- it is pre-1.0 and tightly shaped by Zed's needs;
|
|
- framework documentation and third-party component coverage are still young;
|
|
- the complete dependency and license closure must be audited before adoption;
|
|
- Zed's editor, terminal, and Markdown application crates are GPL-3.0-or-later,
|
|
so Lumbridge cannot copy those implementations into an Apache-2.0 release.
|
|
|
|
### Floem
|
|
|
|
Floem is the strongest independent comparator. It is MIT-licensed, pure Rust,
|
|
fine-grained and reactive, renders through wgpu/Vello or Skia, and is proven in
|
|
the Lapce editor. Its editor primitives may shorten the path to a native
|
|
Markdown/code surface without binding Lumbridge to Zed's application code.
|
|
|
|
Risks:
|
|
|
|
- it is also pre-1.0 and has a smaller ecosystem;
|
|
- current releases carry custom windowing integration that needs maintenance
|
|
review;
|
|
- accessibility, IME, embedded-browser parenting, and multi-window behavior
|
|
still need validation on every target desktop.
|
|
|
|
## Viable fallback
|
|
|
|
Iced is MIT-licensed, cross-platform, and renderer-agnostic with a wgpu path. It
|
|
has approachable architecture and broad examples, but its own documentation
|
|
still calls it experimental. It is a sound fallback if GPUI and Floem fail the
|
|
spike, though Lumbridge would build more IDE/editor infrastructure itself.
|
|
|
|
## Useful building blocks, not the shell decision
|
|
|
|
- `winit + wgpu + cosmic-text` gives maximum renderer control and is a sensible
|
|
direction for a dedicated terminal canvas. Owning an entire desktop toolkit,
|
|
editor, IME, accessibility layer, menus, drag-and-drop, and window integration
|
|
in the first release would be too much product risk.
|
|
- `egui` is excellent for internal diagnostics and rapid prototypes. Its
|
|
immediate-mode model and non-native visual conventions make it a weaker main
|
|
IDE shell.
|
|
- `wry` can host a tightly isolated system-web-engine child for browser panes:
|
|
WKWebView on macOS and WebKitGTK on Linux. It must not become a web frontend or
|
|
a privileged bridge into the session runtime.
|
|
- `AccessKit` should provide the semantic accessibility tree regardless of the
|
|
rendering framework.
|
|
|
|
The Markdown experience remains native: a rope-backed editor, incremental
|
|
parsing and syntax trees, and a Rust Markdown renderer. Preview links and
|
|
embedded web content cross the browser boundary through a narrow, capability-
|
|
checked interface.
|
|
|
|
## The decision spike
|
|
|
|
Build the same disposable shell in GPUI and Floem before product implementation:
|
|
|
|
- workspace sidebar, tab strip, split tree, command palette, footer, and six
|
|
fake busy terminal panes;
|
|
- native Markdown edit and preview surface;
|
|
- browser placeholder followed by one isolated system-web-engine child;
|
|
- semantic test identifiers, keyboard-only navigation, accessibility tree, IME,
|
|
copy/paste, drag-and-drop, and window restore;
|
|
- package and launch on macOS, Ubuntu, and Omarchy/Arch.
|
|
|
|
Record, do not estimate:
|
|
|
|
- cold and warm startup;
|
|
- idle RSS and RSS with six panes;
|
|
- key-to-present p50/p95 and output-to-present latency;
|
|
- frame time while all panes stream output;
|
|
- binary and installed size;
|
|
- accessibility/IME correctness and native window behavior;
|
|
- build/package friction and the complete dependency/license closure.
|
|
|
|
Choose the framework whose measured result gives Lumbridge the best input and
|
|
streaming latency without failing accessibility, packaging, or maintainability.
|
|
If the results are close, prefer the smaller operational and licensing risk.
|