On Tue, 5 Nov 2024 22:01:10 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
>> `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. > > Perhaps I am not entirely clear. But having these examples helped, thanks. > > My point is that, in my opinion, we don't need two classes. We only need > one, with a single `'center'` property. If the app needs > leading/tailing/upper/lower/anythingElse, the app is free to use any > container suitable for their need. > > This way the platform provides the basis, which only the platform can provide. > > So my suggestion would be to combine two classes into one with a single > `'center'` property. > > What do you think? I see where you're coming from. While that might be a possible way to skin the cat, I think it has a few downsides. It would remove most API from `HeaderBar`, and instead, as you say, accept a single node as content. This would shift the concrete API from `HeaderBar` to whatever node/pane/layout container is placed in it. However, the layout container inside this hypothetical header bar would, for many scenarios, need to have back-references to the header bar in order to achieve its purpose, either directly or indirectly by inspecting its own parents. One example is the centering behavior currently implemented for `HeaderBar.center` with a center-aligned node: it needs to know how wide the system insets are to compute the layout. This would mean that a layout container needs to be created that is aware of the context in which it is used, and changes its behavior (or maybe only meaningfully works) if it is placed in a `HeaderBar`. So even recreating the current `HeaderBar` would lead to a bad and potentially fragile API. This, in my opinion, rules out the approach to shifting all layout behavior to a user-supplied layout container. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1830093724
