On Tue, 5 Nov 2024 20:41:01 GMT, Michael Strauß <mstra...@openjdk.org> wrote:
>> 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`.
thanks for explanation. but does it really warrant a base class, couldn't the
app either set different components inside the existing HB, or maybe set a
different HB?
is there anything that HeaderBar does that may not be needed in a custom title
bar?
it just feels that HBBase is not needed.
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829997063
