On Tue, 5 Nov 2024 21:02:28 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
>> 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. We need to think of this in terms of the user model. `HeaderBar` gives rise to three named areas (leading, center, trailing) and comes with a certain layout behavior for each of those areas. Sure, it is possible to place another layout container in the `HeaderBar.center` area and set its prefWidth to infinity in order to effectively get rid of all of the custom layout behavior that `HeaderBar` brings to the table. But that severely limits application and library developers from customizing the user model of the header bar. For example, using `HeaderBarBase`, a library developer can create alternative header bars with a different set of features and a different user model. Those alternative header bars might have different layout areas, different properties, in short a different API. It would be really awkward to shoehorn all of that into the (opinionated) API of `HeaderBar`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1830013578
