Thanks for the background info, Michael -- also, my knowledge of basic JavaFX layout is surprisingly abysmal (compared to other areas), I didn't expect it could be fixed as easily like that (or without affecting *other* nodes or something negatively).
I would consider this a ControlsFx bug based on what you've said so it would be good to get it fixed there as I'm sure many will fall to this in time. Anyway -- I've been testing a bunch of HeaderBar/EXTENDED scenarios at this stage, and all is currently looking good... Kind Regards, Cormac On Tue, 24 Jun 2025 at 19:06, Michael Strauß <michaelstr...@gmail.com> wrote: > We had a brief discussion back in October 2024 whether HeaderBar > should be a normal layout container in the scene graph, or whether it > should live somewhere else (for example something like > Scene.setHeaderBar(), analogous to Scene.setRoot()). It became clear > that we wanted HeaderBar to be a part of the scene graph, because its > capability to interact with the rest of the scene graph is one of the > main features. > > This naturally exposes HeaderBar to the same question that the rest of > the scene graph has to solve: what to do in case of an overconstrained > layout? Layout containers have different (but well-specified) answers > for this question. In your example, you're using a StackPane as the > root layout container. By default, StackPane will center its content > if it can't be resized to fit the available space. This behavior can > be adjusted with the StackPane.alignment property: set to TOP_LEFT, > the HeaderBar in your example will stay where it is. > > The way I see it, there's an easy solution: use the scene graph the > way it's designed and meant to be used. If ControlsFX wraps the scene > root in a StackPane, but doesn't set the content alignment to > TOP_LEFT, then that's a bug in ControlsFX because it changes the way > the scene graph is laid out. >
