On Fri, 2 May 2025 10:32:42 GMT, Michael Strauß <mstra...@openjdk.org> wrote:
>> Implementation of >> [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strauß has updated the pull request incrementally with one additional > commit since the last revision: > > simplify header area picking Several people have commented on an artifact that can happen when the window is resized down below the minimum size of the header bar. In this case, the default window buttons will be drawn over the header bar content. Obviously, this doesn't look good. I've experimented with a potential solution, where I added a new `HeaderBar.clipSystemInset` boolean property. If set to true, the content of the header bar is clipped to always exclude the side of the header bar that contains the window buttons (the red rectangle indicates the clipping rect): <img src="https://github.com/user-attachments/assets/716f6f7d-b95e-4706-b331-cab467cd7d1b"; width="300"/> This works, but there are a few aspects to consider: 1. Clipping the header bar content requires me to put the content inside another container, and then clip this inner container. So the structure of the header bar looks like this: `HeaderBar` -> `ContentContainer` -> [children]. This is unusual for a layout container, which usually doesn't have an internal substructure. 2. The clipping approach works in trivial cases, but it doesn't work as easily in more complex cases. Consider an application like Chrome, where the header bar could conceivably be the entire region marked with a red rectangle: <img src="https://github.com/user-attachments/assets/70d7287e-0b9d-4a39-aea4-2ec65873797f"; width="400"/> The naive approach of clipping away the entire side of the header bar that contains the default window buttons wouldn't work here. We would probably need a more complex clipping shape that fits the design semantics of the application's header bar. 3. Then there's the question of whether we _really_ need this feature. It adds to the complexity of the implementation, and its value is debatable: an application should be designed so it doesn't need to rely on naive content clipping. It should define an appropriate minimum window size, and the window contents should gracefully adapt to small window sizes. In fact, Chrome doesn't clip its header bar content, but scales it down to small icons and then prevents sizing the window below a reasonable minimum size. The same is true for Windows Explorer, Notepad, Spotify, and many other apps. The only application that comes to mind that clips its header bar content is IntelliJ. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2846959953
