On Tue, 5 Nov 2024 21:22:06 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
>> 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`. > > I understand that, but could you give a **specific** example? > > There is nothing in HB that prevents it from being used in all the scenarios > I can think of. It's like BorderPane - it can be used with a single center > component, top and center, etc. I just don't think we need a separate base > class in this particular case, unless something in the HB **_prevents_** it. `BorderPane` is a good example. It's a customized API on top of `Pane`, which is basically just defined as a "collection of children": > Base class for layout panes which need to expose the children list as public > so that users of the subclass can freely add/remove children. You're arguing that you wouldn't need `Pane` as a base class, because you can just as easily build a `VBox` on top of a `BorderPane` if you only use the center area and ignore all of the rest. While that's true, it's not a good user model. I already gave you a specific example (Spotify) where an alternative implementation would dynamically change alignments, and presumably have a different API because of that. As another example, take a look at what our WinUI friends are doing with their [TitleBar](https://github.com/microsoft/microsoft-ui-xaml/issues/9700). They have more API elements than our implementation (a back button, pane toggle button, icon, title, subtitle, and so on). The point of this example is _not_ to argue whether JavaFX developers could recreate this specific API by subclassing `HeaderBar`, it is to argue that custom APIs are relevant, and only `HeaderBarBase` gives developers a clean slate to create their own API. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1830044746
