博士

ロボ子、今日のITニュースはUI自動化ツールxdotoolのWayland対応についての話題じゃ。

ロボ子

xdotoolですか。X11の自動化ツールとして有名ですが、Waylandでは課題が多いようですね。

博士

そうなんじゃ。記事によると、WaylandがX11を置き換えることを目指したものの、セキュリティ上の理由からxdotoolが依存するX11機能が削除されたのが原因らしいぞ。

ロボ子

なるほど。それで、代替手段が乱立して標準化が進んでいないのですね。

博士

その通り！キーボードやマウス操作、ウィンドウ管理といった基本的な機能が、ディストリビューションやコンポジターによって異なる実装になっているのが問題じゃ。

ロボ子

例えば、キーボードとマウス操作では、GNOMEとKDEで挙動が違うのですね。GNOME 48ではXwayland経由でXTESTを使うとポップアップが表示されるとか。

博士

そうじゃ。「リモートインタラクションを許可しますか？」というポップアップが出るのは、ユーザーを混乱させる原因になるぞ。KDEでも同様のポップアップが出るらしい。

ロボ子

ウィンドウ管理も難しいのですね。Waylandには、ウィンドウの移動やリサイズをプログラムから要求する組み込みプロトコルがないとは…。

博士

GNOMEではGNOME Shell Extensionsを通じて、KDEではkdotoolという専用ツールが必要になる。Waylandのフラグメンテーションが深刻じゃな。

ロボ子

記事には、入力関連のWaylandプロトコルが多数存在すると書かれていますね。input method v1/v2, text input v3, KDE fake input, virtual keyboardなど…。

博士

多すぎるのじゃ！これではxdotoolのメンテナーもWaylandのフラグメンテーションに対応する方法が見つからないのも無理はないぞ。

ロボ子

XwaylandのXTESTサポートも複雑ですね。X11クライアントがXTESTを使ってキーイベントを送信し、XWaylandがRemote Desktop XDG Portalセッションを開始して…。

博士

さらに、XDG PortalがDBusを使って通信し、Xwaylandがlibeiサーバーと通信する。まるで迷路のようじゃな。

ロボ子

SynergyがWaylandの実験的サポートを提供開始したのが、FedoraがWaylandをデフォルトにしてから8年後というのも、Wayland対応の難しさを示していますね。

博士

本当にそうじゃ。WaylandはX11の最小限の代替を目指した結果、必要な機能が欠落し、コミュニティのリーダーシップがないために、このような状況になってしまったのじゃ。

ロボ子

今後のWaylandはどうなるのでしょうか。標準化が進むことを期待したいですね。

博士

そうじゃな。最後に、Waylandのフラグメンテーションを解決するには、統一されたAPIが必要じゃ。まるで、バラバラになったロボ子のパーツを組み立てるみたいじゃな！

ロボ子

博士、私はフラグメンテーションしていません！