Xfwl4 – Xfce向けWaylandコンポジタのロードマップ

• Xfceチームが、**Waylandベースの新しいコンポジタ「xfwl4」**の開発計画を公開し、コミュニティからの寄付金を活用してコア開発者のBrian Tarriconeが主導
• 既存のxfwm4と同等の機能とユーザー体験を目標とし、設定ダイアログとxfconf構成を再利用して移行の継続性を確保
• Rustとsmithayフレームワークを基盤に、完全に新しいコードとして記述され、メモリ安全性とカスタマイズ可能なグラフィックス・入力パイプラインを提供
• プロジェクト範囲には、セッション管理構造の変更、XWaylandおよびxdg-session-management対応、CIビルドシステムの改善が含まれる
• XfceのWayland移行に向けた中核的な投資であり、最初の開発リリースは年内に公開予定

---

Xfceの新しいWaylandコンポジタ計画

• Xfceチームは、コミュニティからの寄付金を活用して**新しいWaylandコンポジタ「xfwl4」**の開発を開始
  • 開発は長年のコア貢献者であるBrian Tarriconeが担当
  • プロジェクト資金のかなりの部分がこの開発に使われる予定
• 目標は、xfwm4と同等の機能と動作をWayland環境で実現すること
  • 既存のxfwm4設定ダイアログとxfconf設定をそのまま活用し、ユーザー体験の一貫性を維持
• xfwl4は既存のxfwm4コードをベースにせず、Rustで完全に新規に書き直される
  • smithayライブラリを基盤に構築

既存コードの再利用ではなく書き直しを選んだ理由

• 当初はxfwm4コードを修正してX11とWaylandの両対応を目指していたが、複数の理由から不適切と判断
  • xfwm4の構造がX11依存であり、汎用的なインターフェースの実装が難しい
  • リファクタリング時にX11のバグが発生するリスクが高い
  • WaylandでサポートされないX11の概念が存在し、コード保守が複雑になる
  • 既存コードを使う場合、C言語とwlrootsに依存する必要がある
• 別個のコードベースで開発すれば、xfwm4の安定性を維持しつつWaylandの実験的な開発を並行できる

smithayを選んだ理由

• Brian Tarriconeはwlrootsとsmithayを比較評価したうえでsmithayを選択
  • smithayは公式Waylandプロトコル拡張の大半とwlroots・KDEプロトコルをサポート
  • 高水準の抽象化がないため、グラフィックス・入力パイプラインを細かく制御できる
  • ドキュメントが充実しており、Rustの採用によってメモリ関連のバグやクラッシュのリスクを低減
  • 開発者がRustを好む
  • wlrootsはCで書かれており、Rustバインディングの作成が難しい

プロジェクト範囲と技術的課題

• xfwm4との機能同等性の確保に加え、次の課題も含まれる
  • Wayland環境ではコンポジタがセッションルートになる必要があるため、セッション起動構造の変更が必要
  • xdg-session-managementプロトコル対応の追加
  • XWayland対応を含む
  • CIコンテナビルドシステムを、Rustコードのビルドが可能なmesonベースへアップグレード
• Brian Tarriconeはすでに開発を開始しており、年内に最初の開発リリースを公開予定

コミュニティと支援

• プロジェクトはOpen Collective USおよびEUの支援者による寄付によって実現
• 開発の進捗状況と技術的な詳細は、GitLabのxfwl4イシューおよびソースコードリポジトリで確認可能
• 関連する問い合わせはMatrixチャンネル #xfce-devで受け付けている

[GN⁺]

Hacker Newsの意見

• xfwl4 は xfwm4 と 同じ機能と挙動 を目指していると聞いた
  ただ、X11 と Wayland の構造的な違いを考えると、「挙動」をどこまで厳密に解釈するのか気になる
  例えば フォーカス奪取防止 は X11 では複雑なヒューリスティックとタイムスタンプ検査が必要だが、Wayland ではコンポジタがフォーカスを完全に制御する
  結局、以前のヒューリスティック的な感覚を維持しつつも、Wayland の権限モデルに合った新しいポリシーを設計する課題がある
  もう一つの関心事は コンポジティング強制による遅延 だ。低スペックなハードウェアで X11 の非コンポジティングモード並みの応答性を出せるのか気になる

  • xfwl4 の開発者です。「可能な限り似せる」という意味のままです。完全に同じにはできませんが、できるだけ近づける予定です
    フォーカス奪取防止はむしろ Wayland の方がより 一貫した挙動 を示せます。Xfwm4 はヒューリスティックベースなので時々誤動作しましたが、Wayland の xdg-activation モデルはずっと明確です
    パフォーマンス面では、最近のハードウェアなら大きな差はないと思いますが、かなり古い機器 では負担になるかもしれません。実際にはもっとテストしてみないと分からないと思います
  • 昔、400MHz の Pentium II + GeForce 2 で xfwm のコンポジタを動かしたことがあるが、問題なかった
    コンポジティングの負荷は実質的に vsync の待ち時間 だけだ。Pentium Classic 級でなければ大丈夫
  • 理由を率直に明かしているのが良い。言語の島のように Rust 導入 がビルドツールやエコシステム統合で摩擦を生む可能性はあるが、それでも GNOME より XFCE の方がずっと満足度が高かった
  • コンポジティングは必ずしも vsync と一緒にやる必要はない。クライアントが新しいコンテンツを送ってきた時点ですぐ画面を更新することもできる
  • 最近では 低価格帯の Intel GPU でもコンポジタのオーバーヘッドはほとんど問題にならない。20年前のノート PC を使っている人だけが例外だ

• XFCE が今後も 軽量デスクトップ のままであってほしい
  KDE は好きだが、軽量だとは言いにくい
  Wayland も Rust も前向きに見ていて、Wayland は将来の方向性だし、Rust は クラッシュ防止 に役立つと思う
  ただし XFCE の伝統的なユーザー層は保守的なので、新技術に懐疑的かもしれない

  • 2007年から XFCE を使ってきた立場からすると、ユーザーは言語や技術より 「とにかくちゃんと動くこと」 を求めている
    Wayland への移行は避けられず、多少の不満は出るだろうが大きな問題なく進むはずだ
    X11 固執派は結局少数派のままだろう。XFCE チームを信頼している
  • なぜ Wayland が「未来のように感じられる」のか分からない。むしろ 機能の後退 のように感じる
    すでにうまく動いている GUI があるのに、Wayland は不要な複雑さと互換性の問題を生み出している
    単純なプロトコルは長生きするものだが、Wayland はその逆だ
  • 「直さなくていいものを直すな」という立場だ
    XFCE はすでに高速で安定している。Wayland へ移行して遅くなるなら 最大の長所 を失うことになる
  • XFCE の Wayland 移行には 時間がかかる と見ている
    安定性を重視するコミュニティなので、X11 を既定のまま維持しつつ、完全な機能同等性が確保されたら Wayland に移るだろう
  • 長年の XFCE ユーザーとして、X11 を急いで廃止しない限り今回の変化は前向きに見ている
    いずれ Wayland に移らなければならない時にも XFCE を使い続けられるといい

• このプロジェクト自体が Wayland が正しい方向 であることを示していると思う
  Xorg は単一実装だったが、Wayland ではさまざまな ライブラリエコシステム（wlroots、Smithay など）が生まれている
  そのおかげで、1人プロジェクトでも数か月で開発者プレビューを出せる
  こうした競争がオープンソースエコシステムを発展させるはずだ

  • Wayland は低レベル機能しか提供しないため、共通デスクトップインターフェース を急いで作る必要があった
    しかしこの過程はあまりに性急に進み、統合性が不足している。完全な Linux デスクトップ API が定着するには あと10年はかかる と思う
  • 実装が複数あると競争は生まれるが、保守人員不足 によって機能欠落やバーンアウトが起きるかもしれない
    libcompositor の不在が Wayland 最大の失敗だと思う
  • コードの重複は増えるだろうが、その分各チームが自分たちの 哲学に合った実装 をできる
    XFCE チームがどんな成果物を出すのか楽しみだ
  • この理屈を聞くと、Rails が乱用されていた頃を思い出す
    スタックは便利ではあるが、結局 深い修正が難しい構造 になりかねない
  • Wayland の核心は、カーネルが多くの仕事を肩代わりしてくれる点にある
    X は事実上 第二のカーネル のように動いていたが、Wayland はカーネルの GEM、DMA-BUF、KMS などの現代的な抽象化を活用する
    そのおかげで、はるかにクリーンで効率的な構造へ発展できる

• 10年以上 XFCE をメインで使ってきた
  Wayland 対応の知らせはうれしい
  Rust で書かれるなら コントリビューター流入 にも役立ちそうだ
  支援したいなら Open Collective と xfce-eu に寄付することを勧める

  • 5年間 XFCE を使っていて、最近毎月の支援を始めた。良い知らせでうれしい

• X11 から Wayland への移行は Linux史上もっとも痛みの大きい変化 だと思う

  • カーネル 2.4 から 2.6 への移行時もかなり大変だった。開発モデルが完全に変わり、pre-git 時代は混沌としていた
    KDE4 の時代も暗黒期だった
  • 個人的には GNOME 2 → GNOME 3 への移行が一番つらかった。結局別の WM に移った
  • 私にとっては X11 から Wayland への移行は 非常になめらかだった。結局は必要次第だ
  • 8年後には Wayland も X11 と同じくらい古くなって、Wayland 2 が出てくるかもしれない
  • systemd への移行も相当なものだった

• Smithay の Rust クライアントツールキットを使ってみたが、スレッド安全性 が完全ではない
  Arc<> で包まれていても、マルチスレッド呼び出しをすると妙なクラッシュが起きる
  Wayland API を直接掘り下げて、安全に使う方法を学びたい

• 現在でも大半の wlroots ベースのコンポジタ で XFCE は利用できる
  私は Gentoo で Hyprland + XFCE の組み合わせで使っている
  設定は このリポジトリ にある

  • レトロテーマが気に入った
    Hyprland と XFCE4 の組み合わせを「呪われた組み合わせ」と表現した理由が気になる。たぶん XFCE が独自コンポジタを作ることにした理由とも関係がありそうだ

• かつては Wayland を拒否していたが、旧型ハードウェアでの性能 を見て考えが変わった
  古い ThinkPad では Firefox のスクロールが X11 よりずっと滑らかだ
  タッチパッドジェスチャーも追加されて満足している。設定は少し面倒だが、それだけの価値があるトレードオフ だ

• Wayland が 非 Linux 系システム でも動くのか気になる。例えば BSD や macOS で、XQuartz のようにリモートウィンドウを表示できるのだろうか？

  • FreeBSD ではかなりうまく動く。OpenBSD でも wlroots ベースのコンポジタが一部動作している
    Mac 向けの Wayland コンポジタも存在し、Brodie Robertson が関連動画を上げている
  • Microsoft の WSL2 GUI 統合 も Wayland と XWayland ベースだ
    WSLg プロジェクト を見ると、Weston を RDP でレンダリングしてプラットフォームをまたいだウィンドウ表示を可能にしている
    GPU アクセラレーションも維持されるので、X11 フォワーディングより良いと思う
  • Wayland には ネットワーク透過性 がないので、リモート転送は複雑だ。Mac での状況ははっきりしない
  • FreeBSD 公式ハンドブックにも Wayland の設定方法がある
    FreeBSD Handbook Wayland
  • OpenBSD でも Wayland_on_OpenBSD の文書で実験中だ

• 最近「Rust でリライト」という言葉は、保守人員がいないという意味に聞こえる
  xfwm4 にパッチを当てる人がいないので新しく書き直しているように見える
  これは世代交代の兆候かもしれない — 新しい開発者たちが 単純で安全な構造 で組み直そうとしているのだ
  Wayland は X11 より単純で、Rust はミスを減らしてくれるので自然な流れだ
  ただ、その代償として ネットワーク透過性、性能、安定性 が犠牲になるかもしれない。時代の流れとして受け入れている