* 問題: invalidate() して draw() 内で子を作るようにしてると、プロパティ変更直後には高さが正しく取れない。ListBox のレイアウト等で不都合が出る。
 * メモ: ListBox で ILayout で表現しきれないような複雑なレイアウトが必要な場合は大人しく layoutItems メソッドをオーバーライドする。
 * 検討: boxWidth/boxHeight/contentWidth/contentHeight は必ずしも物理的な高さとは限らない (TextFieldTextAreaのスクロールが微妙)
 * 検討: ComboBox が微妙。 ComboBox というか自前で labelField とか付けたときの話かも。
 * 検討: 子の初期化方法がクラスによってバラバラなので統一したい。(AbstractScrollBarとか)
 * 検討: ListBox の itemContainer に適用したい scrollRect の w/h が boxWidth/boxHeight とは違うことがある。
 
BEComponents - ゆるふわ愛されコンポーネント

「我々の要求に完璧に応えきるコンポーネントを人類が作るのは到底不可能である」 — フレックス・ワ・モウイ・ヤダ (2003-2005)

フレックス氏がこのような格言を吐くのも無理は無い。再利用可能なコンポーネントを開発するのは至難の業なのである。
なぜなら、コンポーネントは機能とデザインが密接に絡み合っているからである。これらを完全に分離するためには、
今後これらに対して生み出される全ての要求を見通すぐらいの先見の明が必要であろう。そのような人が現在までに、そして
これらも居ないであろうことは、既に世にあるコンポーネントライブラリを見れば明らかである。機能は良いがデザインが
思い通りにならない、デザインは良いが機能が思い通りにならない、そのような経験は誰にでもあるだろう。その最たる例が
Flex コンポーネントで、デザイン的な要求が高いプロジェクトでは全く歯が立たないのは誰しもがご存知であろう。
そもそも、ありとあらゆるものを予め詰め込むことによって完璧なコンポーネントを目指そうとしたのが誤りだったのでは
ないかと思う。我々が肉付けすることによって、はじめて完成するコンポーネントがあっても良いのではないか？その方が
使いやすいのではないか？BEComponents はこのような発想に基づいたライブラリである。用意している各要素は、その
要素のアイデンティティとなる最小限の実装のみがされている。ユーザーは、各要素を、カスタマイズしたり、組み合わせたり
することが大前提となって作られているのである。率直に言って、素のままの状態では全く役に立たない。画面に何も表示
されないものすらある。しかし、そこにあなたの実装を加えることによって、あなたにとって完璧なコンポーネントがたちまち
完成するのである。なんて面倒なライブラリなんだ、と思うかもしれない。しかし、既にあるものをなんとかねじ曲げようと
するよりも、しっかりとした土台の上に積み重ねていく方が遥かに簡単であろう。ねじ曲げるのに今まで掛けた時間を思い出して
みて欲しい。BEComponents は素晴らしい土台を提供するのである。

を完璧に体現するライブラリが作れたらいいにゃー。