Rust製クロスプラットフォーム GPUI コンポーネント

 (github.com/longbridge)
18 ポイント 投稿者 GN⁺ 2025-10-28 | 1件のコメント | WhatsAppで共有
  • RustベースのGPUIフレームワークを活用して、クロスプラットフォームのデスクトップアプリケーションを構築できるUIコンポーネントライブラリ
  • 60以上のネイティブスタイルUIコンポーネントを提供し、macOS・Windowsのデザイン感覚とshadcn/uiのモダンな美学を融合
  • 仮想化テーブル、高性能コードエディタ、Markdown/HTMLレンダリング、チャート可視化など豊富な機能を内蔵
  • テーマシステム、多言語対応(i18n)、ドッキングレイアウトなど、拡張性とカスタマイズ性を重視した設計
  • Rustエコシステムにおいて、Iced、egui、Qtなどと比べても、モダンなUIスタイルと大規模データ処理性能で差別化された意義を持つ

プロジェクト概要

  • gpui-componentはRustで書かれたクロスプラットフォームのデスクトップUIコンポーネント集で、GPUIレンダーエンジンを基盤として動作
    • 目標は、“fantastic desktop applications”を高速かつ一貫した方法で構築できるようにすること
    • 公式サイトは longbridge.github.io/gpui-component
  • Apache-2.0ライセンス

主な機能

  • 豊富なコンポーネント構成: 60以上のUI要素を含み、ボタン・リスト・テーブル・チャート・エディタなど多様な構成を提供
  • ネイティブ感覚のデザイン: macOSとWindowsの標準コントロールに着想を得て、shadcn/uiスタイルを組み合わせたモダンなインターフェースを実現
  • 簡潔な使いやすさ: 状態を持たないRenderOnceコンポーネント構造により、シンプルで直感的なコード記述が可能
  • テーマおよびカラーシステム: ThemeとThemeColorを通じて、複数テーマおよび変数ベースの設定をサポート
  • 柔軟なレイアウト: Dock layoutにより、パネル配置、サイズ調整、自由なタイル型構成が可能
  • 高性能レンダリング: Virtualized Table/Listで大規模データも滑らかに表示
  • コンテンツレンダリング: Markdownと簡易的なHTMLをネイティブにサポート
  • チャート機能: 内蔵チャートでデータを可視化可能
  • コードエディタ: 最大20万行まで対応するLSPベースの高性能コードエディタを含む
    • 診断、自動補完、hoverなどの機能をサポート
  • シンタックスハイライト: Tree Sitterを用いて、エディタとMarkdownの両方に構文ハイライトを提供

技術スタックと統計

  • 言語構成: Rust 98.2%、Tree-sitter Query 0.8%、HTML 0.2%、Shell 0.2%、Python 0.1%、C 0.1%
  • リポジトリ指標: 5.4k stars、223 forks、45人以上の貢献者
  • 最新リリース: v0.3.1 (2025年10月27日)

要約的な意義

  • gpui-componentはRustエコシステムにおいて、モダンなUI/UXと高性能レンダリングを組み合わせた新しいデスクトップUIフレームワークとして評価されている
  • 既存のRust GUIフレームワークの限界を補い、大規模データ処理・テーマ化・Markdown統合など実務向けの機能を提供
  • 今後のRustベースのクロスプラットフォームアプリ開発における標準化されたUIレイヤー候補として注目されるプロジェクト

関連記事

1件のコメント

 
GN⁺ 2025-10-28
Hacker Newsの意見

  • Rust UIエコシステムの中では、これは今まで見た中で最も完成度の高いコンポーネントコレクションに見える
    まだユースケースはほとんどないが、ドキュメントは徐々によく整理されてきている
    同様に完成度の高い別の例としては fyrox-ui がある。ただし fyrox エンジンの外ではほとんど使われていない
    Rust UIは着実に成熟してきているが、iced、egui、dioxus、slint のような人気フレームワークは、コンポーネントの完成度という面ではまだ不足しているように見える
    追記すると、このプロジェクトは Rust UIエコシステムにおける大きな前進を示している。
    すべてのコンポーネントを見られるウィジェットギャラリーアプリはここから実行できる — cargo run --release ですぐ試せる

    • gpui は Zed Editor から切り出されたプロジェクトなので、実際の利用量は他の Rust UI クレートよりはるかに多そうだ
    • Fyrox は Rust ゲーム開発に対する懐疑感を抱かせる存在だ。最も成熟したエンジンなのに誰も使っていない。一方で Bevy の ECS にだけ人々が熱狂している。結局のところ、システムそのものにしか興味がなく、本当にゲームを作りたかったわけではないように見える
    • Rust UI フレームワークはまだ急速に変化中なので、完成度が低く見えるのだと思う。それでも勢いは確実にある。個人的な経験にすぎないが、すでに Rust でエンタープライズ級の UI を作ることはできた
    • Longbridge アプリを実際にインストールしてみたが、本当にMac のネイティブアプリのように自然に動く。Electron よりずっと滑らかに動作する
    • ウィジェットギャラリーアプリは印象的だが、900個以上の依存関係があるのは少し気になる。GUI アプリではこれくらいが普通なのかはよく分からない

  • 最も単純なサンプルですら1000個以上の依存関係を持っている。GTK、GDK、pango といったツールキットに依存している。さらに別のツールキットにも依存する構造は少し奇妙に感じる

    • GNOME がサーバーサイドデコレーションを実装していないため、libadwaita に依存する必要がある。これが GTK 関連の依存を全部引き込む原因のようだ
    • Linux ではこういう構造はよくある。トップレベルウィンドウやメニューを描くために GTK や Qt を使うのは一般的だ
    • 小さくて組み合わせ可能な依存関係が1000個あるほうがよいと思う。巨大な単一コードベースよりずっと監査しやすい
    • 最近の Rust プロジェクトがだんだんこういうふうに大きくなっていくのは残念だ

  • オープンソースの多くの基盤技術がトレーディングや暗号資産の企業から生まれているのは複雑な気持ちになる。それでも社会に何らかの貢献をしているという点は前向きに見られる

    • gpui は Zed.dev チームが保守しており、Longbridge は Longbridge Proアプリ を作っている普通のブローカレッジ企業に見える。特に問題になるような点はなさそうだ
    • ビットコイン的な精神はハッカー文化に似ていると思う。「壊れているものを直そう」という姿勢だ。短期的な痛みが長期的な利益につながることもある
    • Rust や OCaml（Jane Street）のような一部のエコシステムではそうした傾向があるが、全体としては誇張された主張に思える
    • React を作った Facebook は Cambridge Analytica スキャンダルやロヒンギャ虐殺のような出来事に関わっていた。そう考えると、トレーディングや暗号資産の企業がオープンソースに貢献するほうが、むしろ道徳的にましかもしれない

  • 最近の「モダン」な UI ツールキットにはビジュアルUIエディタがないのだろうかと気になる
    Qt には QtCreator や QtDesigner のようなツールがあり、ドラッグ＆ドロップだけで UI を作れた
    それに、Qt 関連の比較表の一部項目は間違っている — たとえば最小バイナリサイズや QSyntaxHighlighter の説明など

    • Slint のようなフレームワークは Figma 統合をサポートしており、Qt Design Studio のように使える。昔のネイティブ GUI デザイナーがどれだけ強力だったか、今はあまり知られていないようだ
    • 完成度の高いコンポーネントライブラリを土台にすれば、こうしたビジュアルエディタも Rust で実装できる。XML／マークアップベースの構造をマクロで結び付け、リアルタイムプレビューアプリを作れば Glade や XAML のように動かせる
    • Qt の最小サイズは実際には 20MB 未満だが、一般的には 30〜40MB 程度だ。Core、Gui、QML、Widget モジュールがそれぞれ 8MB 前後あるので、Hello World でも 2〜3個は必要になる
    • Qt Designer は単純な UI には向いているが、カスタムスタイリングを適用するとすぐ破綻する。だから結局は手動で UI ファイルを書くようになった。そのほうがずっときれいで小さくなった
    • Qt6 がテーマをサポートしていないというのは完全に誤りだ

  • 残念ながらこれはフレームワークだ。つまり独自のイベントループを持つ必要がある
    すでに別のループがある環境では統合が難しい。一方で egui は単に各フレームごとに呼ばれるライブラリ型の構造だ

  • 視覚障害者向けのスクリーンリーダーアクセシビリティがきちんと機能するのか気になる

    • 自分では実行していないが、公式ドキュメント によれば ARIA 仕様をサポートしている。必要なラベルと説明を追加すればよい
    • ただし Zed Editor はスクリーンリーダーに対して完全に不透明だ。なので大きな期待はしていない
    • 新しい UI フレームワークを見るたびに、真っ先に聞くのがアクセシビリティについてだ

  • 「ネイティブ」とは、Web ではないという意味なのか、それともOS の標準ウィジェットを使うという意味なのかが気になる。Java の世界でもこの違いにはかなり苦しめられた

    • macOS だけが本当の意味でネイティブアプリを作れるプラットフォームだ。Linux は GTK/Qt に分かれ、Windows はあまりに多くのフレームワークが混在していて、WebView ですらネイティブっぽく見えることがある
    • ここでいうネイティブとは「Web ではない」という意味だ。GPU API で直接描画する構造になっている
    • つまり、ネイティブ実行ファイルではあるが、OS ウィジェットを使っているわけではない
    • OS 統合はなく、完全に独自レンダリング方式だ

  • このフレームワークが**アクセシビリティ（a11y）**を実装しているのか気になる。Rust UI は見た目はきれいでも、アクセシビリティ要件が出てきた時点で全面的に書き直しになることが多い

    • アクセシビリティを重視するなら Dioxus を検討する価値がある。ただし、このレベルまで完成したコンポーネントライブラリはまだない
    • GPUI は Zed チームが作った基盤の上にあるが、スクリーンリーダーには依然として不透明だ。アクセシビリティが重要なら Slint や Qt（cxx-qt）のほうがよく、System76 が Iced を採用したので、そちらも改善されていきそうだ
    • アクセシビリティは実装されている

  • 仮想化されたリストとテーブルの機能は本当に素晴らしい。多くの UI フレームワークではこれを自前で実装しなければならず、不便だった

  • Rust には GUI ツールキットは多いが、再利用可能なコンポーネントコレクションは不足している
    このコレクションは有用そうだが、ほとんどは Web フレームワークのコンポーネント一覧に近い。ネイティブ特化の要素は webview くらいしかない。ファイルを開くダイアログのようなものは rfd のような外部ライブラリを使う必要があり、スタイルの一貫性が崩れる

    • スタイルの一貫性が崩れるのはむしろ良いことだ。ユーザーはアプリ間の一貫性を求める。つまり、OS ネイティブのダイアログのほうが馴染みやすい。Blender や Photoshop のようなプロ向けソフトは例外だが、一般的なアプリならネイティブのほうがよいと思う
    • ほとんどの UI ライブラリにも、最低限のネイティブ統合は必要だ。ショートカット、システムメニュー、ファイルダイアログ、コンテキストメニューのようなものだ。こうした部分がユーザーにとっての親しみやすさを高める
    • ファイルピッカーは必ずOS 標準のダイアログを使うべきだ。自前実装は望ましくない