Thank you, Michael, this clarifies a lot. And thank you for updating the JEP.
In the table, you mention "custom implementation" for resize borders. What does it mean (who is providing the implementation?) Also in the table, please add "right click to invoke the system menu" (this might be a windows-only feature), and the "window shadow" row. I see the native code in your PR refer to iOS, but not Android. Can you add the two columns to the table (even if they are N/A right now)? In the "Superimposed window buttons" section, you mention that the window buttons automatically adapt to the Scene background, yet on Windows (10, I think) the color of buttons is a user-selectable item, as far as I remember. Can you elaborate, maybe with examples (in the JEP)? "the system-reserved areas will be empty" meaning non-null (0,0), right? "With the absence of a system-provided header bar, the click-to-drag and double-click to maximize behaviors are lost." I read it as the application code must re-implement this functionality, yet afterward you say the HeaderBar provides it. May be it should read "... behaviors would be lost" or something to that effect. The main thing I want to know from reading the JEP is what parts the application developers should implement and what is provided by the new feature. "leftSystemInset and rightSystemInset" properties. How does this work on RTL platforms? Do these properties retain their left/right semantics, or should they be renamed leading/trailing? For HeaderBar: what are the steps to ensure that the height of the bar is exactly the same as the native? Same question, but with two initial conditions: the children that can be enlarged or shrink, and the children that might have a minimum size, like TextArea for instance. What happens if the header bar width is less than the minimum size of its children? Should the trailing children slide out of the view, or should the children be squished beyond their minimum size? Could this be an option? Could this be controlled in the same manner as the GridPane, for example? Is the header bar always clipped? Minor question: should there be an explicit safeguard against creating two HeaderBars, or placing them in the unusual place? An exception perhaps? I hope most of your answers will end up as clarifications in the JEP, as the JEPs are typically the first thing an application developer looks in when trying to understand the new feature. Thank you for your work and patience! -andy From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of Michael Strauß <michaelstr...@gmail.com> Date: Thursday, October 24, 2024 at 14:30 To: Cc: openjfx-dev <openjfx-dev@openjdk.org> Subject: Re: JEP: JavaFX controls in the title bar > One suggestion: in the "what is the EXTENDED stage style?" section, is it > possible to provide a table showing which elements are provided by the OS and > which are provided by FX, and which are not provided, per platform? I've added a table with some information to the JEP. > Also, since the JEP mentions that platform buttons are "superimposed", does > it mean FX can style and place things underneath the platform decorations? Yes, that's possible. Aside from the Scene itself, applications might want to place a background image below the window buttons. > Is the platform title bar background used in the area occupied by the > platform buttons, or only the buttons are superimposed? Only the buttons themselves are superimposed, the background is left entirely to JavaFX. This could also potentially include transparent/translucent window backgrounds in the future, if we ever get this feature. > HeaderBar: I think the requirements / rules for this component need to be > further explained/clarified. Can an app add two HeaderBars? What happens > when the HeaderBar is added at the bottom? I've added an API note explaining that while technically possible, an application should not do these things because it would lead to a bad user experience. > Or maybe the EXTENDED style needs to create the top level container > automatically so there is only one header bar which is on top? This would unnecessarily bifurcate the JavaFX scene graph into two distinct parts. Keep in mind that we want maximum flexibility for applications, and that includes the option to have controls that span the client and header area. Take the Chrome browser as an example: you have essentially a TabPane where the tabs are located in the header area, and the tab content is located in the client area. This requires us to have a single scene graph. > When the header bar is empty, does it have the minimum height - maybe > determined by the platform buttons or a typical platform title bar height? Maybe. But should we? Let me think about that. > As an alternative, maybe we should, instead of inventing a new stage style, > provide a Region that hosts the native open/close/system menu/... buttons? > Or do we actually need the EXTENDED style for its borders and shadows? The EXTENDED stage style is required for two reasons: 1. It gives us native borders, shadows, and window animations; none of these are available with the UNDECORATED style. Especially on Windows, there is quite a bit of native code required to make this work. 2. Crucially, it activates the machinery for all of the window behaviors (window buttons, dragging, snap layouts). This is different from all of the other styles, because it requires bidirectional communication with the JavaFX application: for example, when the native window manager determines whether a dragging behavior should be started, is usually knows exactly whether you clicked on the title bar (because the title bar is provided by the window manager). With custom title bars, however, the window manager doesn't know that. So it needs to call into JavaFX and ask the scene graph whether a header bar is at the click coordinate.
