> Let's consider the typical case of a root container that is either a > BorderPane or a VBox, with a HeaderBar in the top portion of the > BorderPane or as the first (top) child of the VBox. In that case, the > root container will size the HeaderBar to its preferred height. If there > are no children of the HeaderBar, will its preferred height then be the > height of the system-reserved area for window buttons?
The default preferred height of HeaderBar is USE_COMPUTED_HEIGHT. For a header bar without children, the actual height will therefore depend on the root container. BorderPane.top, VBox: the height is zero StackPane, HBox: the height spans the entire container > How do you figure out which one gets the system-reserved area, and thus > the window buttons? The one whose "y" value is lowest (i.e., the > top-most one)? The first one encountered in scene graph traversal order > (typically, but not necessarily, the same)? Something else? The window buttons are not part of the HeaderBar, so no instance "owns" those buttons. The buttons will appear where the platform wants them to be, and a well-behaved HeaderBar will consider this during layout. Of course, it is possible for application developers to use HeaderBar in a way that would not be considered well-behaved (not placing it at the top of the scene, for example). > That's sort of what I guessed. I think it might be a good idea to add an > API note suggesting that an application have only one HeaderBar > positioned at the top of the Scene. I've updated the PR with an API note to that effect. > It might be a good idea to make the standard examples that you include > in the docs show the case where it isn't over-constrained, and then > maybe have an example where it is. I've updated the JEP with a better example that clearly shows the centering behavior.
