Comments on StageStyle.EXTENDED

[Thiago Milczarek Sayão]

I attempted to implement rounded corners on GNOME, but ran into some
limitations:

   -

   *JavaFX rendering pipeline*: JavaFX has its own rendering pipeline,
   which cannot be mixed with GTK3’s. Since GTK3 handles rounded corners and
   window clipping through CSS, integrating the two is problematic. I did
   manage a partial solution with some very ugly hacks, but it’s not worth
   pursuing further.
   -

   *GTK4 with DMA-BUF*: On recent GTK4 versions, this becomes possible by
   using *DMA-BUF*. JavaFX could render into a DMA-BUF, which GTK would
   then composite. That would allow a GTK window with a JavaFX scene embedded
   inside it, while still overlaying GTK-based window controls. However, this
   would require major changes, essentially tied to implementing full Wayland
   support. In that case, I’d prefer to go directly with native Wayland (since
   Wayland itself is just a protocol, with compositors like Mutter on GNOME
   and KWin on KDE).
   -

   *GNOME’s CSD approach*: GNOME relies on *Client-Side Decorations (CSD)*,
   meaning the toolkit (GTK) is responsible for drawing window frames and
   controls. This already results in some differences between applications.
   For example, on macOS Tahoe, windows vary in appearance, with larger
   control buttons and different corner radii. Since visual differences are
   acceptable today, one possible approach would be to handle this at
the *JavaFX
   level*:
   -

      Implement a custom Scene or Effect for rounded corner clipping and
      drop shadows.
      -

      On native glass, use set a transparent visual and use
      gdk_window_set_shadow_width to inform the window manager about the
      shadow area, so it won’t treat it as part of the window.



Em sex., 19 de set. de 2025 22:01, Michael Strauß <michaelstrau2 at gmail.com>
escreveu:

> This comment was received on the design document for the extended
> stage style [0]:
>
> > Linux -> Rounded Corners -> need investigation:
> > The biggest issue is, that Gnome, for example, has pretty round
> > windows by default, making the app look even more alien (custom
> > color scheme and controls). Since I can't adjust the Stage's
> > background, I have no means to do corners by myself (which I
> > already did, when I created a custom window decoration for the
> > app).
>
> This was also brought up by Thiago during the development of this feature
> [1].
> For the extended stage style we're using an undecorated window which
> doesn't have rounded corners. What you'd probably need to have for a
> custom-drawn approach is a stage style like EXTENDED_TRANSPARENT,
> which seems to be very niche. In any case, EXTENDED is a replacement
> for DECORATED, which means that it shouldn't be the responsibility of
> the application developer to draw window decorations. So we're not
> there yet when it comes to rounded window corners on Linux.
>
>
> > Linux -> window buttons in general:
> > On Gnome it's actually pretty rare to have three buttons at all.
> > maximised is done via double click on the header, leaving
> > minimizing and closing. But I can't change the visibility (or
> > order) of the buttons.
> > Additionally, native buttons can be configured in which order
> > (and on which side) they are. I don't know if the current
> > implementation takes that into account.
>
> The current implementation does not take a custom button order into
> account, and there is no API to change the button order or visibility.
> This might be a future enhancement.
>
> By the way, if you don't want the default buttons, you can pretty
> easily bring your own buttons instead (see the documentation of
> StageStyle.EXTENDED). If you own the buttons, you can change order and
> visibility as you like.
>
>
> [0] https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09
> [1]
> https://mail.openjdk.org/pipermail/openjfx-dev/2024-October/050141.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250920/b490b9fd/attachment-0001.htm>