RFR: 8313424: JavaFX controls in the title bar [v3]

Tue Oct 22 04:29:14 UTC 2024

Hello,

Thank you so much for your effort! I'm really glad this hasn't been
forgotten. I wouldn't say it's just popular demand; it's an absolute must.
Here are a few thoughts, if you don't mind.

Every modern platform supports this feature: Electron, Tauri, Wails, Qt,
and even Swing via FlatLaf. If you use IntelliJ or VSCode, you can see it
for yourself. It's a popular design trend, which is why there's so much
demand.

Unfortunately, the current UNDECORATED stage implementation lacks two
important things: shadows and smooth resizing. Implementing shadows is
tricky but possible. However, achieving smooth resizing with Java code
alone is not feasible. There are several implementations on StackOverflow,
but they tend to be jerky and not very performant.

That's why the implementation should be handled on the native side, which
isn't something an app developer can do. We can only patiently wait for
this feature to be integrated into the core JavaFX platform.

It's indeed a complex feature. For that reason, I believe the
implementation shouldn't provide platform-dependent window controls. It
should be left to app developers to dodge theming issues. In Linux, for
example, it's common to install 3rd-party themes or decorations. You never
know what decorations the end user will use, and OS developers can change
themes over time too. It's just simpler to support this feature as a
separate library, which I'm sure will be developed.

вт, 22 окт. 2024 г. в 03:24, Michael Strauß <mstrauss at openjdk.org>:

> On Mon, 21 Oct 2024 10:55:53 GMT, Thiago Milczarek Sayao <
> tsayao at openjdk.org> wrote:
>
> >> Michael Strauß has updated the pull request incrementally with one
> additional commit since the last revision:
> >>
> >>   revert unintended change
> >
> > A few points observed on Linux:
> > 1) It's possible to resize it to 1px using the provided functionality
> with `gtk_window_begin_resize_drag`. An then it's not possible to resize
> back. The Headerbar should block resizing to the size of window controls.
> > 2) It's not possible to move the window if the cursor is over a control.
> Maybe you should just  `gtk_window_begin_move_drag`  when a drag is
> detected, not on click. That would be on
> `WindowContextBase::process_mouse_motion`;
> > 3) The application is closing if the click happens on the top right
> corner (that's because it's triggering the close button instead of resizing
> (I think  2 should solve it as well). It closes with:
> > `(java:16179): Gtk-CRITICAL **: 07:34:26.721:
> gtk_window_begin_resize_drag: assertion 'gtk_widget_get_visible (widget)'
> failed`
> > 4) Alt + F8 is working (it's a desktop shortcut for resizing the window)
> - just pointing out to include in manual testing;
> > 5) I think rounded edges should be supported on the HeaderBar, since
> it's the default on gnome. For that to work, `EXTENDED` should be also
> transparent on Linux. It would loose the window drop shadow which can be
> added on the JavaFX side. `gdk_window_set_shadow_width` should be called
> with the drop shadow size, so the desktop will know the correct window
> bounds.
> >
> > Added later:
> > 6) It should have a "focused" state/pseudo class because on gnome (maybe
> others) the focused window has a different background on the HeaderBar
> which is darker.
> > 7) Suggestion: Maybe make window states stylable on the HeaderBar with
> pseudo-classes like `:maximized`, `:fullscreen`, `:focused`, `:solid` (when
> it does not have rounded corners). Then it would be possible to CSS style
> it.
> > 8) Maybe integrate with platform preferences and provide a way to CSS
> style it when it's Light or Dark?
> >
> >
> > Nice cleanup on `Window.java` . `UndecoratedMoveResizeHelper` was not
> going to work on Linux anyways.
>
> @tsayao Thanks for the comments. I'll have a look at the bugs that you
> found.
>
> > 2. It's not possible to move the window if the cursor is over a control.
> Maybe you should just  `gtk_window_begin_move_drag`  when a drag is
> detected, not on click. That would be on
> `WindowContextBase::process_mouse_motion`;
>
> I know that dragging on interactive controls is a thing on Linux, but I
> don't think that we should be doing that. JavaFX applications are
> multi-platform apps, which means that their behavior should be consistent
> across platforms. Stealing mouse interactions on interactive controls is
> not a thing on Windows and macOS, and this has the potential to cause
> problems for application developers.
>
> If you want, you can declare any node in the header bar to be draggable on
> all platforms with `HeaderBar.setDraggable(Node, boolean)`.
>
> > 5. I think rounded edges should be supported on the HeaderBar, since
> it's the default on gnome. For that to work, `EXTENDED` should be also
> transparent on Linux. It would loose the window drop shadow which can be
> added on the JavaFX side. `gdk_window_set_shadow_width` should be called
> with the drop shadow size, so the desktop will know the correct window
> bounds.
>
> I'll have to look into that, but in general an `EXTENDED` window should
> work out of the box for all platforms, without platform-specific changes on
> the JavaFX side.
>
> > Added later: 6) It should have a "focused" state/pseudo class because on
> gnome (maybe others) the focused window has a different background on the
> HeaderBar which is darker. 7) Suggestion: Maybe make window states stylable
> on the HeaderBar with pseudo-classes like `:maximized`, `:fullscreen`,
> `:focused`, `:solid` (when it does not have rounded corners). Then it would
> be possible to CSS style it. 8) Maybe integrate with platform preferences
> and provide a way to CSS style it when it's Light or Dark?
>
> While that sounds useful at first, I don't think it carries its own
> weight. Many platforms use different styling for windows that are focused
> vs. windows that are not. This not only includes the header bar, but many
> other parts of the user interface as well. I don't think that we should be
> adding what would essentially be ad-hoc pseudo-classes _only_ to HeaderBar.
>
> In addition to that, it is extremely easy for an application to do this by
> adding a listener to `Stage.focused` and then toggling pseudo-classes on
> all relevant controls.
>
> We should _definitely_ not do pseudo-classes for light vs. dark mode. The
> correct way to solve this problem is with media queries
> ([prefers-color-scheme](
> https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme)
> ).
>
> -------------
>
> PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2427910290
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241022/367f812e/attachment-0001.htm>