ラボユース合宿スライド下書き
目次
プロジェクトの概要
合宿で行ったこと
プロジェクトの概要
概要
Linuxにおけるウインドウマネージャ開発に現代的な設計・開発環境を取り入れる
ウインドウマネージャ(WM)とは
GUI環境を管理するソフトウェア
GUI部品の管理
クライアント (ウインドウ) の管理
位置関係、前後関係、親子関係など
入出力デバイスの管理
画面の描画
イベントの管理
ユーザーの入力を解釈し、クライアントの振る舞いに反映する
例
ウインドウの右上端で左クリックされた！
→ ウインドウを削除し、メモリを開放
ウインドウの端がドラッグされた！
→ ウインドウをリサイズする
X11が主流だが、Waylandに切り替わりつつある
これまでの流れ
最初の計画:
「X11での開発を想定しつつ、少ない変更でWaylandにも対応できるウインドウマネージャ」を開発する
設計のアプローチ(ビジネスロジックの分離)によって実現
誤解: WaylandをX11と同じくくりで考えていた
実際は両方ディスプレイサーバーではなく、あくまでプロトコルやアーキテクチャを定めたもの
Wayland自体は画面の描画や入出力デバイスの管理を提供しない
Xサーバーに委ねることもある (Waylandアーキテクチャの中にXサーバーがある状態)
Waylandに基づいた実装を理解する必要がある
目標
WM開発に現代的な設計・開発環境を取り入れる
開発環境の課題
現状、ほとんどのプロジェクトがCによるもの
開発者個人が考慮すべき事項の多さ (コードの規則や、メモリ管理など)
設計方針の統一の難しさ (抽象化を実現する明確な仕様がない)
モダンな言語を取り入れることで
コードの規則やメモリ管理における秩序を統一しやすくなる
Web開発などで普及しているさまざまな設計手法を取り入れやすくなる
それなら、設計もモダンにしたい
設計の課題
外部環境の変化に対する強さ
外部環境に影響する/しない処理をどう切り離すか？
「外部環境」の例
ディスプレイサーバー、入出力デバイス、クライアントなど
それらの機能とアクセスするためのライブラリも含む
一般的には、外部環境に依存しない設計が望ましい
ウインドウマネージャは、外部環境の種類が多い
変化に強い設計にするには、それらに影響する/しない処理を明確に書き分ける必要がある
そもそも切り離す必要があるのか？
他の分野に比べて、外部環境や開発ツールの変化(流行り廃り)のスパンが長い
数十年単位
メンテナンスのしやすさ　
主要な部品 (ウインドウ、カーソル、レンダラーなど)の管理を別モジュールとして切り分けたい
明確に切り離せると
テストができる
各モジュール/ソースファイルの役割がわかりやすくなる
コンポジタ開発におけるドメイン=関心事とは何なのか？
より良い設計にするために、どんな特性が重要なのかを見極めたい
プロジェクトで行うこと
設計手法の調査
現在議論されている設計手法を理解する
Waylandの理解
検証用のWaylandコンポジタを開発し、全体像を掴む
実装
想定成果物は、これらの課題のモデルケースとなる実装の公開
Rustによる実装を検討
ドキュメント整備
発表前に調べ直すべきこと
過去はどのような設計がされてきたのか？
DRM/KMSとはなにか？