JEP: JavaFX controls in the title bar

[Michael Strauß]

> I presume that the preferred width and height of HeaderBarBase is the
> width of the window and the height of the system-reserved area for
> window buttons?

HeaderBarBase is a resizable `Region`, and as such has no preferred
width or height. It is an abstract base class that is only intended to
provide very basic functionality.
HeaderBar is only realistically useful when contained in another root
container, since otherwise your application won't have a useful client
area where child nodes can be placed. The root container then
determines the size and location of the HeaderBar.


> Are leftSystemInset and rightSystemInset read-only?

Yes. Also, they are only informational and are not entangled with any
layout behavior of `HeaderBarBase` (which is just a `Region`).
Implementations can (and most likely should) use this information in
their own layout calculations.


> What is the behavior if an application adds more than one HeaderBar?
> What if they add a HeaderBar that isn't positioned at the top of the
> Stage? What is the behavior if an app adds a HeaderBar to a DECORATED or
> UNDECORATED Stage?

More than one HeaderBar:
The window will have two header bars, both working basically as one
would expect.

HeaderBar not at top:
The header bar will work as expected. However, the
leftSystemInset/rightSystemInset will (perhaps unexpectedly) still
contain the dimensions of the system-reserved window button area at
the top of the window. The meaning of those properties is not "the
size of the area that is geometrically obscured by window buttons on
this concrete HeaderBar, given its non-standard placement", but it's
literally just the size of the system insets on the window.

HeaderBar in DECORATED/UNDECORATED stage:
The header bar will still be a regular layout container, and the user
interface will still appear as expected. However, leftSystemInset and
rightSystemInset will both be empty. Dragging and double-click to
maximize will not work.
This essentially means that an EXTENDED stage with HeaderBar can
gracefully downgrade to DECORATED without exhibiting weird behaviors.


> I want to make sure I understand the centering policy: To my eyes, the
> text field in the macOS example is not horizontally centered in the
> window. Is this a bug or am I misunderstanding something?

Yes, it's not centered because there's not enough available space in
the header bar, given the minimum size of the text field.
HeaderBar will try to keep it centered, but only while it can still
honor its minimum size; after that, the content will be shifted.
It is a bit difficult to easily describe the behavior, but it's
obvious when you see it working.


> As Andy already mentioned in the PR, the `EXTENDED` StageStyle should be
> a ConditionalFeature, similar to TRANSPARENT or UNIFIED. Oh, I see from
> the PR that you already did this. Can you update the JEP to indicate this?

Done. I've also added that the system insets will be empty when
HeaderBar is used with a stage style other than `EXTENDED`.


> And speaking of UNIFIED, it might be worth mentioning the differences
> between EXTENDED and UNIFIED. Somewhat related to this, we have talked
> about deprecating (not for removal) UNIFIED and always returning `false`
> from `ConditionalFeature.isSupported(UNIFIED_WINDOW)`.

UNIFIED doesn't seem to be usefully working on any platform, does it?
It might be hard to explain the difference to a feature that doesn't
really work. I'll think about it.