Hi Michael,
I like this proposal overall. It provides a commonly-requested feature
with a minimal API surface. While I share some of the concerns about
implementing it, it is reflective of modern UI design on all of the
desktop platforms, so I expect the platform vendors to continue
supporting the features this needs to run.
You had mentioned in your PR the possibility of making this a preview
feature, which seems like a good idea. I think it is worth reviving the
preview feature proposal, and to consider using it for this feature.
I have a few overall questions after an initial reading of the JEP. I'll
take a closer look and send more specific feedback.
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?
Are leftSystemInset and rightSystemInset read-only?
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?
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?
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?
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)`.
-- Kevin
On 10/22/2024 4:55 PM, Michael Strauß wrote:
Hi everyone,
the discussion in PR #1605 has shown that the proposed feature needs a
better presentation in a JEP-like format, so here it is:
https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09
