サイボウズ・ラボユース 成果発表会 (第13期)
Linuxウインドウマネージャ開発を通じた
多田 瑛貴 Teruki TADA システムソフトウェア研究開発 (星野ゼミ)
多田 瑛貴 Teruki TADA
公立はこだて未来大学 システム情報科学部 2年
地図・FLOSS・グラフィックス
コンピュータのGUI環境上で
などの管理を行うソフトウェア
参考: Window manager - ArchWiki https://wiki.archlinux.org/title/Window_manager
良い設計を目指したWMの実装
(現在も開発中)
https://storage.googleapis.com/misskey-tadateruki-main/misskey-tadateruki-main/8d92d5b8-3875-4769-90a1-41286d1fe048.mp4
X11に対する指摘の例: Gajewska, Hania et al. “Why X is not our ideal window system.” Software: Practice and Experience 20 (1990): n. pag.
WM開発を通して、適切なソフトウェア設計について議論
現代の主要なユースケースを軸とし 保守性・可用性・拡張性に優れた モデルケース的なWMを開発する
言語はRustを選定 メモリ安全性や処理速度に優れているほか ポリモーフィズムを取り入れた設計が適用可能
X11はクライアント・サーバーモデル
XWindow: X11におけるウインドウ
位置・大きさ・前後関係等など ウインドウの状態はXServer側が持つが
それらを操作するのはWM側
操作のたびに、状態の取得や変更のための通信が発生
キャッシュをしない場合 冗長な通信によるパフォーマンス低下
キャッシュをする場合 状態が複製され、変更時に整合性が取れない場合がある
本プロジェクトにおいては、リモート操作を ユースケースとして考慮しないこととし 原則キャッシュをせず、常に問い合わせる 判断を行った
これは、WMのユースケースに強く依存 X11Forwardingでのリモート操作をサポートする場合は再検討の必要あり
X11に依存する処理を分離したい
テスタビリティ について
議論の末、以下の処理を分離することに
ウインドウの位置・大きさの計算 タイトルバーとアプリケーションの同期をはじめ 整合性の求められる部分をカプセル化 X11では、タイトルバーも独立したXWindow
装飾の描画内容 描画機能を別ライブラリに委譲 (Cairo) ウインドウに描画する代わりに、画像で出力して確認 (現在未実装) GUI操作はX11の機能に依存するため、基本的には分離不可能
他環境への移植性 について
X11とそれ以外で、ソフトウェアのモデルが大きく変わる 抽象化できる層が薄く、メリットを得られない
よって、この点は考慮しないことに
X11の問題点の多くは、そもそもX11のモデル自体に起因している
ここでは アプリケーションのXwindow (App) + タイトルバー等装飾用のXWindow (Frame) を組み合わせたオブジェクトを「Client」として扱う
全体像
Clientに関する イベントの処理
Clientの描画時
Clientとして 扱われない XWindowの処理
X11プロトコルを用いたWM開発において 状態の分離とX11環境への依存が課題
WMの主要なユースケースに合わせ 状態の整合性とテスタビリティを優先した設計を行った
現在も開発継続中である
Waylandプロトコルでは、XServerとWMにあたる部分が Compositorとして一体化されている
よりシンプルなモデルで、状態の分離を解決
ただし、今までXServer (Xorg) が抽象化していた ハードウェアを扱う処理も同時に担うため、開発が困難である
本プロジェクトでは、現状扱わないが 今後の課題として、Waylandの場合での設計を議論したい