114 sizes for this purpose.
115 <p>For example, to override the preferred size of a ListView:</p>
116 <pre><code> listview.setPrefSize(200,300);
117 </code></pre>
118 <p>Or, to change the max width of a button so it will resize wider to fill a space:
119 <pre><code> button.setMaxWidth(Double.MAX_VALUE);
120 </code></pre>
121 <p>For the inverse case, where the application needs to clamp the node's min
122 or max size to its preferred:
123 <pre><code> listview.setMaxSize(Region.USE_PREF_SIZE, Region.USE_PREF_SIZE);
124 </code></pre>
125 And finally, if the application needs to restore the intrinsically computed values:
126 <pre><code> listview.setPrefSize(Region.USE_COMPUTED_SIZE, Region.USE_COMPUTED_SIZE);
127 </code></pre>
128
129 <h3>CSS Styling and Node Sizing</h3>
130
131 Applications cannot reliably query the bounds of a resizable node until it has been
132 added to a scene because the size of that node may be dependent on CSS. This is
133 because CSS is used to style many aspects of a node which affect it's preferred size
134 (font, padding, borders, etc) and so the node cannot be layed out (resized) until
135 CSS has been applied and the parent can access valid size range metrics.
136 This is always true for Controls (and any panes that contain them), because they
137 rely on CSS for their default style, even if no user-level style sheets have been set.
138 Stylesheets are set at the Scene level, which means that styles cannot even
139 be determined until a node's enclosing scene has been initialized. Once a Scene
140 is initialized, CSS is applied to nodes on each pulse (when needed) just before
141 the layout pass.
142
143
144
145 <h3>Visual Bounds vs. Layout Bounds</h3>
146
147 A graphically rich user interface often has the need to make a distinction between
148 a node's visual bounds and the bounds used for layout. For example, the tight visual
149 bounds of a Text node's character glyphs would not work for layout, as the text
150 would not be aligned and leading/trailing whitespace would be discounted. Also,
151 sometimes applications wish to apply affects and transforms to nodes without
152 disturbing the surrounding layout (bouncing, jiggling, drop shadows, glows, etc).
153 To support this distinction in the scene graph, {@link javafx.scene.Node Node}
154 provides the {@code layoutBounds} property to define the 'logical' bounds
171 <th scope="row">{@link javafx.scene.shape.Shape Shape},{@link javafx.scene.image.ImageView ImageView}</th>
172 <td>Includes geometric bounds (geometry plus stroke).
173 Does NOT include effect, clip, or any transforms.
174 </td>
175 </tr>
176 <tr>
177 <th scope="row">{@link javafx.scene.text.Text Text}</th>
178 <td>logical bounds based on the font height and content width, including white space.
179 can be configured to be tight bounds around chars glyphs by setting {@code boundsType}.
180 Does NOT include effect, clip, or any transforms.
181 </td>
182 </tr>
183 <tr>
184 <th scope="row">{@link javafx.scene.layout.Region Region}, {@link javafx.scene.control.Control Control}, {@link javafx.scene.web.WebView WebView}</th>
185 <td>always {@code [0,0 width x height]} regardless of visual bounds,
186 which might be larger or smaller than layout bounds.
187 </td>
188 </tr>
189 <tr>
190 <th scope="row">{@link javafx.scene.Group Group}</th>
191 <td>Union of all visible childrens' visual bounds ({@code boundsInParent})
192 Does NOT include effect, clip, or transforms set directly on group,
193 however DOES include effect, clip, transforms set on individual children since
194 those are included in the child's {@code boundsInParent}.
195 </td>
196 </tr>
197 </tbody>
198 </table>
199 <p>
200 So for example, if a {@link javafx.scene.effect.DropShadow DropShadow} is added to a shape,
201 that shadow will <em>not</em> be factored into layout by default. Or, if a
202 {@link javafx.animation.ScaleTransition ScaleTransition} is used to
203 pulse the size of a button, that pulse animation will not disturb layout around
204 that button. If an application wishes to have the effect, clip, or transform
205 factored into the layout of a node, it should wrap that node in a Group.
206 </p>
207
208 </body>
209 </html>
|
114 sizes for this purpose.
115 <p>For example, to override the preferred size of a ListView:</p>
116 <pre><code> listview.setPrefSize(200,300);
117 </code></pre>
118 <p>Or, to change the max width of a button so it will resize wider to fill a space:
119 <pre><code> button.setMaxWidth(Double.MAX_VALUE);
120 </code></pre>
121 <p>For the inverse case, where the application needs to clamp the node's min
122 or max size to its preferred:
123 <pre><code> listview.setMaxSize(Region.USE_PREF_SIZE, Region.USE_PREF_SIZE);
124 </code></pre>
125 And finally, if the application needs to restore the intrinsically computed values:
126 <pre><code> listview.setPrefSize(Region.USE_COMPUTED_SIZE, Region.USE_COMPUTED_SIZE);
127 </code></pre>
128
129 <h3>CSS Styling and Node Sizing</h3>
130
131 Applications cannot reliably query the bounds of a resizable node until it has been
132 added to a scene because the size of that node may be dependent on CSS. This is
133 because CSS is used to style many aspects of a node which affect it's preferred size
134 (font, padding, borders, etc) and so the node cannot be laied out (resized) until
135 CSS has been applied and the parent can access valid size range metrics.
136 This is always true for Controls (and any panes that contain them), because they
137 rely on CSS for their default style, even if no user-level style sheets have been set.
138 Stylesheets are set at the Scene level, which means that styles cannot even
139 be determined until a node's enclosing scene has been initialized. Once a Scene
140 is initialized, CSS is applied to nodes on each pulse (when needed) just before
141 the layout pass.
142
143
144
145 <h3>Visual Bounds vs. Layout Bounds</h3>
146
147 A graphically rich user interface often has the need to make a distinction between
148 a node's visual bounds and the bounds used for layout. For example, the tight visual
149 bounds of a Text node's character glyphs would not work for layout, as the text
150 would not be aligned and leading/trailing whitespace would be discounted. Also,
151 sometimes applications wish to apply affects and transforms to nodes without
152 disturbing the surrounding layout (bouncing, jiggling, drop shadows, glows, etc).
153 To support this distinction in the scene graph, {@link javafx.scene.Node Node}
154 provides the {@code layoutBounds} property to define the 'logical' bounds
171 <th scope="row">{@link javafx.scene.shape.Shape Shape},{@link javafx.scene.image.ImageView ImageView}</th>
172 <td>Includes geometric bounds (geometry plus stroke).
173 Does NOT include effect, clip, or any transforms.
174 </td>
175 </tr>
176 <tr>
177 <th scope="row">{@link javafx.scene.text.Text Text}</th>
178 <td>logical bounds based on the font height and content width, including white space.
179 can be configured to be tight bounds around chars glyphs by setting {@code boundsType}.
180 Does NOT include effect, clip, or any transforms.
181 </td>
182 </tr>
183 <tr>
184 <th scope="row">{@link javafx.scene.layout.Region Region}, {@link javafx.scene.control.Control Control}, {@link javafx.scene.web.WebView WebView}</th>
185 <td>always {@code [0,0 width x height]} regardless of visual bounds,
186 which might be larger or smaller than layout bounds.
187 </td>
188 </tr>
189 <tr>
190 <th scope="row">{@link javafx.scene.Group Group}</th>
191 <td>Union of all visible children's visual bounds ({@code boundsInParent})
192 Does NOT include effect, clip, or transforms set directly on group,
193 however DOES include effect, clip, transforms set on individual children since
194 those are included in the child's {@code boundsInParent}.
195 </td>
196 </tr>
197 </tbody>
198 </table>
199 <p>
200 So for example, if a {@link javafx.scene.effect.DropShadow DropShadow} is added to a shape,
201 that shadow will <em>not</em> be factored into layout by default. Or, if a
202 {@link javafx.animation.ScaleTransition ScaleTransition} is used to
203 pulse the size of a button, that pulse animation will not disturb layout around
204 that button. If an application wishes to have the effect, clip, or transform
205 factored into the layout of a node, it should wrap that node in a Group.
206 </p>
207
208 </body>
209 </html>
|