== Client ==
ウィンドウマネージャ界隈(?)では、ウィンドウマネージャにmanageされるウィンドウのことをClientというらしい。いくつかのWMのソースを読んだところ、ウィンドウを管理するための構造体名などにClientという名称がよく見受けられる。Xサーバ/Xクライアントという構造では、WMはむしろクライアントの一つだが、要するに「(他の)クライアント」という意味だろう。ウィンドウマネージャは一つのディスプレイに対して同時に一つしか存在しないはずなので問題はないのか。

== いい感じにウィンドウを配置する ==
アグレッシブにウィンドウのサイズを変えまくるとUIのレイアウトが崩壊したりして幸せになれないので、適切な表示サイズが存在するウィンドウに関してはそれを尊重してやらなければならない。少し調べてみた所、だいたい以下の3つに注意する必要があるらしい。
 1. `override_redirect`フラグ: このフラグが立っているウィンドウをウィンドウマネージャは無視すべき(どうやら自前で移動・リサイズ制御を行うウィンドウが設定するらしい)
  * `xwininfo`コマンドで確かめられる。試しにibusのツールバーを調べてみたらyesになっていた
 1. `WM_TRANSIENT_FOR`プロパティ: クライアント側で設定される、一時的なトップレベルウィンドウ(ex.ダイアログボックス)であることを示すプロパティ
 1. `WM_NORMAL_HINTS`プロパティ: クライアント側で設定される、そのウィンドウの標準の状態におけるサイズヒント
  * プロパティは`xprop`コマンドで確かめられる
dwmの実装を読んでみたところ、以下のようになっていた。
 1. `override_redirect`が立っているものは完全に無視(そもそもClientのリストに入れない)
 1. `WM_TRANSIENT_FOR`の設定されているものは、フローティング表示するように設定(isfloating=True)
 1. `WM_NORMAL_HINTS`の設定されているものは、「最小幅=最大幅かつ最小高さ=最大高さ」の場合(要するに厳密にサイズを指定してきている場合)、固定サイズフラグを立て(isfixed=True)、フローティング表示するように設定(isfloating=True)
  * mltermやacroreadの設定ウィンドウはこれに該当する
ということで、このあたりをまともに扱うようにすればある程度は不幸を避けられるはず。

== メモ: サイズヒントの扱いについて ==
全画面型の場合でも考えるべきことが意外と多い。
 * 未設定 -> 問答無用で最大化
 * minw==maxw && minh==maxh -> 単純に尊重。画面に収まらない場合のみが問題(ウィンドウの移動による擬似スクロール?)
 * maxwまたはmaxhが設定されている -> 画面に収まるようなら尊重すべきか
 * min_aspect、max_aspectの扱い
 * 収まらない場合の調整単位: width_inc、height_inc