On Tue, 5 Nov 2024 16:47:00 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
>> Michael Strauß has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> stylistic changes
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBarBase.java
> line 51:
>
>> 49: * can specify draggable content nodes of the {@code HeaderBarBase} with
>> the {@link #setDraggable} method.
>> 50: *
>> 51: * @apiNote Most application developers should use the {@link HeaderBar}
>> implementation instead of
>
> just curious: what's the reason to split the HB into the two classes? Can
> you give an example?
The goal of the JEP is to allow fully customizable header bars (excluding
window buttons). `HeaderBarBase` is the basic building block that is required
for the headerbar-specific features like dragging, double clicking, and so on.
This class is special because its functionality can't be replicated by user
code.
For maximum customizability, `HeaderBarBase` is just a `Region`. Subclasses are
free to implement any kind of control on top of that. This is what `HeaderBar`
is: an implementation on top of the basic functionality, offering a pretty
useful API and layout behavior. It covers many common use cases with the
separation between a leading, center, and trailing area.
But special applications might have special requirements. For example, the
Spotify desktop app selectively hides items in its header bar depending on the
available space, and sometimes dynamically changes the alignment of items. This
would be a case where an application would use a custom implementation of
`HeaderBarBase`.
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829974615
