On Thu, 2 Jul 2026 20:52:09 GMT, Michael Strauß <[email protected]> wrote:
>> JavaFX controls in the title bar were previewed with >> [JDK-8313424](https://bugs.openjdk.org/browse/JDK-8313424) (delivered in JFX >> 25) and the API was subsequently refined with >> [JDK-8369836](https://bugs.openjdk.org/browse/JDK-8369836) and >> [JDK-8370446](https://bugs.openjdk.org/browse/JDK-8370446) (delivered in JFX >> 26). The feedback collected in two preview rounds suggests that the API is >> fit for purpose, and no fundamental changes are required. This means that >> the feature is ready to become final and permanent in JFX 27. >> >> I propose a few small changes to smooth out remaining edges: >> 1. **Rename `HeaderBar.prefButtonHeight` to `HeaderBar.systemButtonHeight`** >> This more clearly expresses that it is the height of the >> _system-provided_ buttons. >> 2. **Rename `HeaderBar.minSystemHeight` to `HeaderBar.systemMinHeight`** >> What is meant is not a _minimum system height_ (which makes no sense), >> but a _system-provided minimum height_. >> 3. **Add `HeaderBar.systemColorScheme`** >> In the previous iteration, the color scheme of the header buttons on >> Windows and Linux was determined by the brightness of the `Scene.fill` >> background. On macOS, which uses header buttons drawn by the operating >> system, the color scheme of the header buttons was instead determined by the >> color scheme of the window itself. >> >> The newly added `HeaderBar.systemColorScheme` attached property allows >> applications to specify the color scheme for system-provided header buttons >> directly, without falling back to either the scene background or the window >> color scheme. The default value of the property is `null`, which means "no >> preference"; in this case, the color scheme for header buttons will match >> the color scheme for the window on all platforms. Setting this property to a >> non-null value is only necessary in the rare case when an application needs >> different color schemes for header buttons and the window (i.e. when it has >> a bright title bar in dark mode, or a dark title bar in light mode). >> >> Since these changes are only cosmetic (in the case of renamed properties) >> and don't fundamentally change the API of the enhancement (in the case of >> `HeaderBar.systemColorScheme`), they shouldn't need to be previewed for >> another round. >> >> The rest of the significant changes in this PR are a clean-up pass over the >> documentation, and having the macOS header button implementation support the >> new `HeaderBar.systemColorScheme` property. >> >> ## Note on the use of attached properties >> This e... > > Michael Strauß has updated the pull request incrementally with one additional > commit since the last revision: > > Move HeaderBar.AttachedProperties to Stage.ExtendedPropertiesImpl I've decided to move `HeaderBar.AttachedProperties` to `Stage.ExtendedPropertiesImpl`. The move itself is quite straightforward and the class implementation doesn't change much; what changes is a significant removal of inter-class communication. Previously, some values were stored as fields directly on `Stage`, while others were stored on `HeaderBar.AttachedProperties`. Both needed to be carefully kept in sync. For example, when a property like `HeaderBar.systemButtonHeight(Stage)` was retrieved, it was initialized with the current value stored on `Stage`. Then, if the attached property value was changed by the user, its new value was pushed back to `Stage`. Moving all of the implementation to `Stage` means that most of the inter-class communciation is not needed. A second and final change is the specification of `HeaderBar.systemColorScheme(Stage)`: previously, this was specified so that `null` means "use the scene-provided color scheme". While that works in principle, it doesn't allow users of `HeaderBar` to easily observe the scene-provided effective color scheme of the header buttons. I've changed this property to match the specification of `Scene.Preferences.colorScheme` as a _null-coalescing_ property: if set to `null`, its value resolves to the value provided by the scene. If set to a non-null value, it overrides the scene value. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2188#issuecomment-4870413272
