XFCE 4.20、初期 Wayland サポートを目標に
(ostechnix.com)- XFCE 4.20 は、軽量な X11 デスクトップ環境という従来の強みを維持しながら、初期 Wayland サポートを中核コンポーネントに取り込む移行リリースとして準備中
- Wayland の導入により、より単純なディスプレイ構造と直接通信を通じて、性能・セキュリティの改善、入力遅延の低減、HiDPI サポートが期待される
- サポート範囲は xfce4-panel、xfdesktop、libxfce4ui、xfce4-settings から始まり、コンポーネントごとに移植と互換性調整が進行中
- ただし xfwm4 の Wayland 開発やパネルプラグイン・アプリケーションの対応が残っており、完全な XFCE Wayland セッションの時期はまだ確定していない
- 開発の方向性は X11 を切り捨てるというより、ユーザーが慣れ親しんだ XFCE 環境を維持しながら Wayland を選択的に試せるようにするものに近い
XFCE 4.20 の Wayland 移行範囲
- XFCE 4.20 は、初期 Wayland サポートを中核コンポーネントに導入することを目標としている
- 従来の XFCE は軽量でカスタマイズ可能な X11 デスクトップ環境として知られており、4.20 は X11 互換性を維持したまま Wayland を追加する
- ユーザーは従来の XFCE 体験を使い続けながら、Wayland 環境を試すことができる
-
Wayland が変える部分
- Wayland は、古い X11 システムを置き換えるよう設計された最新のディスプレイサーバープロトコル
- より単純な構造とアプリケーション—ディスプレイサーバー間の直接通信により、グラフィックスをより滑らかにし、入力遅延を減らし、セキュリティを改善する
- 高解像度ディスプレイを標準でサポートし、最新ハードウェアでより鮮明な画面を提供する
- コンポジターがウィンドウ管理、アニメーション、効果をより効果的に制御する コンポジター中心のアプローチを使用する
コンポーネント別の進捗状況と残作業
-
中核コンポーネント
- xfce4-panel は wlroots コンポジターフレームワークを使って Wayland 向けに調整され、Wayland で動作するよう準備された
- xfdesktop は Wayland に移植され、ワークスペースやウィンドウ一覧などの機能サポートが引き続き進められている
- libxfce4ui は X11 と Wayland の両方の互換性を保証するよう更新された
- xfce4-settings には Wayland 対応コンポーネントが追加され、ディスプレイ設定は X11 と Wayland で別々に動作するよう調整された
-
まだ残っている課題
- xfwm4 の Wayland 開発が残っている
- 複数のパネルプラグインやアプリケーションにも Wayland サポート作業が必要
- 長期目標は完全な XFCE Wayland セッションの提供だが、正確なスケジュールはまだ不透明
XFCE 4.20 のリリース日程
- 現在の XFCE 4.20 リリース計画は次のとおり
- 2024年11月1日: XFCE 4.20pre1、機能および文字列の凍結
- 2024年12月1日: XFCE 4.20pre2、コード凍結
- 2024年12月15日: XFCE 4.20pre3、最終凍結、任意リリース
- 2024年12月15日: XFCE 4.20 最終リリース予定、pre3 がある場合は 2024年12月29日前後
- 参考資料: https://wiki.xfce.org/releng/4.20/roadmap
1件のコメント
Hacker News の意見
念のためはっきりさせておくと、まだコンポジタはない
少し作業はしてみたが、使い物になるまで最低1年、もしかするとそれ以上かかりそう
4.20では一部のコンポーネントを別のコンポジタ上で実行でき、私たちのコンポジタも wlroots を使う予定なので、主に Wayfire と Labwc でテストしている
ただ、この変化に人々がどう反応するかは気になる。XFCE ユーザーの中には Wayland を望む人や気にしない人も多いが、この変化に強く抵抗する人も多そうだ
ゆっくり進めれば、最近の Wayland の成長による利点を取り込みつつ、移行時の問題を最小限に抑えるよう XFCE Wayland を磨けそうに見える
彼らも GTK ベースからだんだん離れつつあるデスクトップ向け Wayland コンポジタを作っていて、かなり進んでいるので、そのコンポジタが要件に合うかもしれない
ついでに言うと XFCE は本当に好き。機能、安定性、性能のバランスが完璧だと感じる
X11 ライブラリが何十億個も散らばっていた混乱を、また避けられるといい
Linux/BSD で設定をいじらなくてもすぐ動いて軽いウィンドウマネージャを探すなら、XFCE が唯一の実用的な選択肢だと本気で思う
デフォルトが全体的に妥当な、より良い Windows 2000 UI のような存在だ。XFCE を継続的に最新の状態に保ってくれている開発者たちには本当に感謝しているし、今回のニュースは大きな朗報だ
それで Cinnamon も「より良い Windows 2000 UI」としてかなり良い選択肢だと分かった
Cinnamon も HiDPI で完璧ではないが、フォントサイズを150%や200%に上げても全体が壊れにくい。XFCE でそれをやるとすべてが見苦しくなる
XFCE は毎日、特に勤務日には使っている
何年も使い続けていて、Atom ベースのネットブックで遅延なく動かせた唯一のウィンドウマネージャだった頃から使い始めた。当時はそれが持っていた唯一の「PC」だった
長い時間が経った今もまだ使っていて、今も満足している。何かをクリックしたときに遅延なく即座に動くのがどんな感覚か、人々は知っているのだろうか
すばらしいソフトウェアであり、関わっているすべての開発者に感謝している
HiDPI への不満をいくつか見たが、役に立つかは分からないものの、4K ノートPC画面、USB-C 接続の 4K モニター、HDMI で縦置きにした 1024 解像度のモニターを使っている
外観設定で x2 を指定すると2台の 4K モニターはとてもきれいに見え、ディスプレイマネージャで 1024 モニターにも 2x スケールを指定すると問題ない。当然 4K ほど良くはないが、そもそも劣るモニターだからで、正直ここまでうまく動くのが驚くほどだ
数か月前に会社のコンピュータへ Linux をインストールしたとき、XFCE が X11 に縛られていたことが、結局 KDE に移る理由になった
リモートマシンでコードをコンパイルしていると、あるウィンドウのターミナルのせいで別ウィンドウの YouTube 動画がカクついた。確認した限りでは、ハードウェアアクセラレーション再生がまったく効いていないようだった
Chrome と Firefox はどちらも X11 を事実上見限り、Wayland で Vulkan ベースのレンダリングバックエンドを使う方向へ進んだように見えた
KDE 5 を一晩「熟成」させた後は、Gentoo なので KDE のようなフルデスクトップ環境のコンパイルには時間がかかるが、すべてがそのまま動いた
XFCE の視覚的なシンプルさは恋しいし、いつか戻りたいが、それまでは応答性が肝心だ
いつも軽くてリソース消費の少ないソフトウェアを好んでいるが、ハードウェアアクセラレーションを使わないのは、むしろリソースを多く食うとも言える
数年前は主に dwm を使っていて気に入っていたが、すぐ環境が必要なときはたいてい Xfce に戻る
家族のコンピュータ、父・母・妹の PC と、面倒でそのままにしているメディア PC まで全部 Xfce だ。Xfce が Wayland をサポートするようになれば、移行を検討すると思う
Xfce 4.0.4 あたりだったと思う動画を見て、バーでランチャーやウィジェットを自分で選ぶ方式がどれほどシンプルで安定しているかに驚いた記憶が今も残っている。当時の Gnome よりずっとシンプルだった
現代の KDE は時々自分には Xfce のように見えることもあるが、設定を変えようとすると奇妙なバグに多く出くわす。Xfce にも Thunar がかなり不安定だった時期のような問題はあったが、それでもシンプルさと安定性の面で自分が戻るデスクトップだ
理由は、みんな Win9x で育っていて、XFCE の視覚的メタファーがすぐ理解できるから。YouTube と Facebook さえ使えれば、中身が何かはまったく気にしない
ついでに言うと dwm はすばらしい。suckless 系の大半がそうであるように
正直、Wayland の画面共有やその他の部分はまだあまりに脆弱なので、デイリードライバーである XFCE が導入で遅れていることが、むしろ利点に感じられる
最初は完全に壊れていて、アプリごとに明示的な対応を追加する必要があり、かなりひどかったように思うが、最近は Firefox、Zoom、Slack では問題なかった
Microsoft Teams だけは例外で、Teams ではウェブカメラすらまともに動かない
ロックダウンで自宅に帰されたとき、Chrome の MS Teams ではデフォルトで画面共有ができなかったが、数分検索して有効にすべき Chrome フラグを見つけ、正しいフラグで起動するローカルの desktop ファイルを新しく作った
それ以降に不足していたのはHDR 対応と色補正くらいだ。まだ準備できていないのは残念だが、実際に使うユーザーはごく少数なので、99.9% のユーザーにとって Wayland はうまく動く
個別のウィンドウやタブの共有が可能なのかもよく分からない
Wayland 側でこれはどうなっているのか気になる
Wayland への移行は、クライアント側装飾の導入とも一緒に進んでいるように見える
この「モダン」なアプローチは、最近の設定マネージャーの変更に見られるように、XFCE の伝統的なユーザー体験を壊している。XFCE の将来が心配だ
自分にとって XFCE の長所は、安定して実装された伝統的な Win98/XP 的ユーザー体験である点だった。Gnome3 のパターンをこれ以上取り入れないでほしい
Wayland への移行とクライアント側装飾は、特に関係ない
GNOME/GTK 側は Wayland 以前からすでに CSD の流れに乗っていた。Wayland コンポジターは自分で装飾を描けるし、xfwm4 も Wayland コンポジターになれば引き続きそうする予定だ
Wayland の実際に良い点の一つは、コンポジターがアプリに対して独自の装飾を描かないよう伝えられるプロトコルがあることだ。一方 X11 では、アプリが CSD を描くとウィンドウマネージャーに言ってきたら、ウィンドウマネージャーにできることはない
GNOME は確かに CSD へ徹底的に進んだし、記憶が正しければ GNOME ではアプリが CSD を描かないと装飾がまったくないが、それは Wayland とは無関係だ
これが Wayland や XFCE と何の関係があるのか分からない。クライアント側装飾を使う主要なデスクトップ環境は事実上 GNOME だけで、これは 2018年からそうだった
出典: https://blog.martin-graesslin.com/blog/2018/01/server-side-d...
Wayland は中立であり、Wayland 上でどうするかはコンポジターとアプリケーションが決めることだ
CSD はユーザー体験とは関係ない。CSD は、アプリケーションがウィンドウボタンと枠を自分で描くという意味にすぎない
自分のアクセシビリティ要件は Wayland では事実上死んでいる
アプリケーションごとに真似できるショートカットと、グローバルショートカットが必要だ
しかし Wayland のセキュリティモデルはこれを許さないように思う。アクセシビリティおよび自動化ツールがすべての Wayland コンポジターをサポートするには、どう持ちこたえるのか分からない
残りはライブラリやツールキットに置けるが、統合ポイントはおそらくコンポジターの中にあるべきだ
https://github.com/rvaiya/keyd
Windows に比べてアクセシビリティがあまりにも遅れていて、笑えもしない
wlroots の上にビルドするという理解で合っている？
だとすれば、かなり歓迎すべき進展だ。Sway や River のような他のウィンドウマネージャー/コンポジターでも、XFCE アプリの堅牢さを享受できるかもしれないからだ
wlroots を使って xfwm4 の作業を少しやってみたが、使い物になるにはまだ 1年以上かかるだろう
Wayland で動作するデスクトップ構成要素は、主に wlroots ベースのコンポジターでテストした
Linux でデスクトップ環境を使う必要があるなら XFCE を使う
しかしこの Wayland の流れのせいで、気持ちは BSD 側に傾きつつある。まだ Linux を捨てたわけではないし、Firefox が X 対応をやめるまでは Wayland が必須になることはなさそうだ
ただし systemd なしで画面共有を動かすのに必要な魔法のような dbus の呪文は、まだ分かっていない。少なくとも pipewire は必要になりそうだ