ドック開発で垣間見えたGTKの設計の変化
ドックアプリケーション
普段はコンパクトで、カーソルを移動すると展開される
https://scrapbox.io/files/64ad10d763ff74001cf57f19.png ⇔ https://scrapbox.io/files/64ad0e42f90e5e001da161c7.png
現在、開発環境がArch+sway
しかし、いい感じのドックがなかった
そこで、自分で作ることにした
(ただ、開発後に見るといい感じのはあった)
GTK4を採用
あくまで経験のあるGTK3の延長のつもりだった
しかし、ドック開発を経て、いろいろと違いを感じた
GTKについて
GUIツールキット
現在はメジャーがGTK3からGTK4に移りつつある状況
もともと使い物にならなかったが、GTK4.6から安定してきた
CSSを使ってスタイルを記述できる
glade (デザインツール) を使ってレイアウトもグラフィカルに調整できる
GTK4プロジェクトについて
GTK4開発の動機について、まだ明確な文献が見つからない
具体的な動機を調べるにはメーリングリストなども追う必要がある
GTK4のもつ新規性やGTK3との違いを公式ドキュメントで明確に提示していないのが非常に引っかかる
なんなら、GTK5 (とそれ以上) に関する雑な言及もある
古い記事ではあるが、正直、このような考えは気に入らない
GTK3からの移行方法を示したドキュメントからいろいろ垣間見える
GTK4の設計の変化
Wayland前提のAPI設計となっている
X11でできることが軒並みサポートされなくなっている
特徴的なのが、各クライアントが、WMの役割をオーバーライドできなくなっている点
例えば
ウインドウの位置の(クライアント自身による)変更
Root windowの利用
グローバルな情報(カーソル位置、ディスプレイ解像度など)のクエリ
Waylandではアーキテクチャレベルで不可能である
Waylandに合わせた設計により、クロスプラットホーム性が増したように見える
GTK3では、X11前提の関数が未だにある状況
一方で、自由度は低下
WMの管理の枠を超えた柔軟なUI設計はおおむね実現不可能に
実現できたとして、WM依存である以上他のプラットフォームでそのまま使うことができず、再利用性がない
自分の作ったドックも、sway側の設定に依存
素直にGUIツールキットとして役割を果たすならこれで十分
WMの役割のオーバーライドは本来UI上の安全性を揺るがすものである
Webフロントエンドでも、各コンポーネントがむやみに他のコンポーネントに影響を与えるプロパティを持っていると問題になる(marginなど)
自由度は明らかに低下したが、デスクトップの治安を脅かす機能をGUIツールキットに求めるのは、ナンセンスかもしれない
UIデザインのためのコーディングが簡潔に
Visualの廃止
色の深度やピクセルのバイトオーダーなどを管理する概念
デバイスに紐付けられている
デバイスからVisualの情報をうまく取り出す必要がある
非常に煩雑な処理
廃止されたことで、描画のハードルが下がったように感じる
デフォルトでウインドウが透過する
透過ウインドウの実装には前述のVisualが必要だったが、廃止
モダンなUI (透明、角丸) の導入が容易になった
一方で、すりガラス(?)は実装が厳しくなった
その他
なんとなくCSSの内容に素直に従うようになった気がする
いろいろと煩わしいものがなくなっている
サブクラスとして作る新しいウィジェットはすべてGtkWidget派生に
Entryなど既存のものが必要になったら、新しいウィジェットクラスの子要素として導入する
Waylandとの親和性が向上し、素直なGUIツールキットとして非常に使い勝手のいいものになった印象
一方で、WM開発に使うには限界がある
GTK3でも厳しかったが、GTK4では (GDKの存在を含めても) 不可能という判断
UIを記述するフレームワークとして使うのはあり
"CSSでカスタマイズできる"というのは、改めて思うとあまりにもありがたいポイント