JEP: JavaFX controls in the title bar

Andy Goryachev andy.goryachev at oracle.com
Fri Nov 15 21:14:47 UTC 2024


Martin:

Are you referring to this (macOS Notes):

[cid:image001.png at 01DB375F.F59057E0]

or something else?

I think the Notes-like UI can be implemented using the proposed HeaderBar (HB), all one needs to do is to bind the width of the left part in the HB to the split pane's divider position, without the need for multiple HB.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Martin Fox <martin at martinfox.com>
Date: Friday, November 15, 2024 at 13:09
To: OpenJFX <openjfx-dev at openjdk.org>
Subject: Re: JEP: JavaFX controls in the title bar
Michael,

On the Mac a common UI layout is to have a splitter view that extends to the top of the window with separate toolbars in each panel. Have you given any thought on supporting this layout in an EXTENDED window?

(I realize this is a Mac thing; Apple loves their sidebars. Microsoft dabbled with this design language but it seems to be fading away. I have seen it in a few Windows apps like 1Password.)

In UIKit Apple implements this using separate views. The equivalent in JavaFX would be to add a separate HeaderBarBase object to the top of each panel in a SplitPane. That would require supporting multiple HeaderBarBase instances and providing an API to tell one to ignore leftSystemInset or rightSystemInset (or both). I like this solution since it allows the background visuals for each header bar to be customized.

The way Apple shoe-horned this into the older AppKit is a bit less elegant. There’s still one NSToolbar that spans the entire window. A developer can add special items to the toolbar that track the dividers in an NSSplitView. I would let developers roll their own solutions if they want that design. Replicating that in JavaFX wouldn’t require any alterations to the HeaderBarBase class and it’s too specialized to be added to HeaderBar.

Martin

> On Oct 23, 2024, at 7:19 AM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241115/b8cbd1d4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 109713 bytes
Desc: image001.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241115/b8cbd1d4/image001-0001.png>


More information about the openjfx-dev mailing list