other: クローンする GetBoundsBox。

クローン化をサポートする GetBoundsBox のサブクラスには、このコンストラクタを呼び出すコンストラクタが必要です。ただし、これらのコンストラクタがそれぞれ自身のオプションをクローン化する場合は、その限りではありません。

layout-valid? が false である場合、このオブジェクトが最初に配置されなかったか、あるいは、このオブジェクトまたはその子孫に対して GetBoundsBox.request-layout が実行されて、新しいレイアウト計算が完了していません。

lc: このレイアウト ネゴシエーションに使用する LayoutContext。

gr: 結果を格納する GRect。

このメソッドは、self に対する width-first レイアウト ネゴシエーションを次のように行います。

1. self.get-width-preference を呼び出します。これにより、幅設定 wpref が返されます。
2. wpref の最初の最後のコンポーネントのユーザー設定サイズを lextent 引数と rextent 引数として self.constrain-width を呼び出します。この呼び出しの結果が、高さ設定 hpref になります。
3. hpref の最初と最後のコンポーネントのユーザー設定サイズをそれぞれオブジェクトのアセントとディセントとして使用して、self.set-size を呼び出します。

この作業の結果、self は、その実際のサイズがユーザー設定サイズになるように配置されます。

上記のメソッドの呼び出し中にレイアウトの無効化 (Graphic.request-layout の呼び出し) が発生した場合、このメソッドはレイアウト ネゴシエーションを繰り返し実行しようとはしません。したがって、get-elastic-bounds-into の呼び出し側が、レイアウトの無効化が発生したかどうかをチェックし (self.layout-valid? が true であるか false であるかを確認し)、レイアウト ネゴシエーションの再試行などの適切な復元処理を実行する必要があります。

gr: 結果を格納する GRect。

このメソッドは、self.get-layout-context を呼び出すことによって LayoutContext を取得して、その取得した LayoutContext と gr を引数として self.get-elastic-bounds-into を呼び出します。

epoch: このレイアウト無効化に関連付けられている Layout Epoch。これは、通常、get-layout-epoch を使用して得られる現在の Layout Epoch です。

一般的に、このメソッドは、Box.request-layout から Box の親にレイアウトの要求を伝えるために呼び出されるか、Layout.request-layout から呼び出されます。

Box でこのメソッドを呼び出すことは、Box のグラフィカルな子孫のいずれかが新しいレイアウト ネゴシエーションを要求していることを示します。この状況は、Box での Box.request-layout の呼び出しとは対照的です。この場合は、Box 自体が新しいレイアウト ネゴシエーションを要求していることを意味します。これらの 2 つの別個のメソッドが提供されるのは、その後のレイアウト ネゴシエーションの初めに Graphic.attempt-revalidate-layout が呼び出されるときに、異なるアクションを保証するためです。Box.propagate-request-layout の呼び出しによって、この Box にレイアウト要求が通知された場合は、Box 自体では何も変更されていないので、Box の子で Graphic.attempt-revalidate-layout メソッドが呼び出されたときにすべての子の答えが true であれば、Box の Graphic.attempt-revalidate-layout に対する答えは常に true になります。しかし、Box.request-layout が呼び出された場合は、Box は、そのすべての子のレイアウトについて有効性を再検証できたとしても、それ自体のレイアウトが有効とは認められない場合があります。これは、グラフィカルな子の追加や削除、またはそれらの子の空白や配列での変更など、Box 自体の構造で変更が加えられている可能性があるからです。

このメソッドは、情報を保持してレイアウト無効化を追跡する Box サブクラスでオーバーライドできます。このようなオーバーライド メソッドにはすべて super.propagate-request-layout の呼び出しが必要です。このメソッドは、グラフィック階層のルートになるように設計されている View などのクラスでもオーバーライドされます。この場合、レイアウト要求を記録し、新しいレイアウト ネゴシエーションに合わせて整列させるコードによってメソッドがオーバーライドされます。

request-layout 操作の実行時に更新される記録情報を持つ Graphic のサブクラスによって、このメソッドをオーバーライドできます。このようなオーバーライド メソッドは、必ず {super.request-layout} を呼び出します。オーバーライド メソッドの例として、BasicBox.request-layout があります。

このオブジェクトで set-size を呼び出すと、オブジェクトのレイアウト サイズを代入し、オブジェクトのレイアウト ネゴシエーションを完了します。グラフィック階層のすべてのオブジェクトにレイアウト サイズが代入された後で階層のレイアウト ネゴシエーションが完了します。

lc: このレイアウト ネゴシエーションに対して有効な LayoutContext。

bounds: このオブジェクトの境界ボックスの左右および上下の範囲をオブジェクトの起点から相対的に示す GRect。

このメソッドは、オブジェクトのグラフィカルな親によって呼び出されます。

既定のメソッド Graphic.set-size は何も行ないません。Graphicのサブクラスはこのメソッドをオーバーライドして、ここで提供した情報をインターセプトできます。

このメソッドは、境界および原点の位置についての情報のクエリができるように Box のレイアウトを有効にする必要があるときに呼び出されます。このメソッドは、一般に、レイアウト システムの一部をなすコードによってのみ呼び出されます。

この抽象メソッドは、Box の 具象サブクラスによって、必要なアクションを実際に実行するコードでオーバーライドされなければなりません。