<div dir="ltr"><div dir="auto"><div dir="auto"><p style="color:rgb(0,0,0)">I attempted to implement rounded corners on GNOME, but ran into some limitations:</p><ul style="color:rgb(0,0,0)"><li><p><strong>JavaFX rendering pipeline</strong>: 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.</p></li><li><p><strong>GTK4 with DMA-BUF</strong>: On recent GTK4 versions, this becomes possible by using<span class="gmail-Apple-converted-space"> </span><strong>DMA-BUF</strong>. 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).</p></li><li><p><strong>GNOME’s CSD approach</strong>: GNOME relies on<span class="gmail-Apple-converted-space"> </span><strong>Client-Side Decorations (CSD)</strong>, 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<span class="gmail-Apple-converted-space"> </span><strong>JavaFX level</strong>:</p><ul><li><p>Implement a custom<span class="gmail-Apple-converted-space"> </span><code>Scene</code><span class="gmail-Apple-converted-space"> </span>or<span class="gmail-Apple-converted-space"> </span><code>Effect</code><span class="gmail-Apple-converted-space"> </span>for rounded corner clipping and drop shadows.</p></li><li><p>On native glass, use<span class="gmail-Apple-converted-space"> set a transparent visual and use </span><code>gdk_window_set_shadow_width</code><span class="gmail-Apple-converted-space"> </span>to inform the window manager about the shadow area, so it won’t treat it as part of the window.</p></li></ul></li></ul></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sex., 19 de set. de 2025 22:01, Michael Strauß <<a href="mailto:michaelstrau2@gmail.com" target="_blank">michaelstrau2@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">This comment was received on the design document for the extended<br>
stage style [0]:<br>
<br>
> Linux -> Rounded Corners -> need investigation:<br>
> The biggest issue is, that Gnome, for example, has pretty round<br>
> windows by default, making the app look even more alien (custom<br>
> color scheme and controls). Since I can't adjust the Stage's<br>
> background, I have no means to do corners by myself (which I<br>
> already did, when I created a custom window decoration for the<br>
> app).<br>
<br>
This was also brought up by Thiago during the development of this feature [1].<br>
For the extended stage style we're using an undecorated window which<br>
doesn't have rounded corners. What you'd probably need to have for a<br>
custom-drawn approach is a stage style like EXTENDED_TRANSPARENT,<br>
which seems to be very niche. In any case, EXTENDED is a replacement<br>
for DECORATED, which means that it shouldn't be the responsibility of<br>
the application developer to draw window decorations. So we're not<br>
there yet when it comes to rounded window corners on Linux.<br>
<br>
<br>
> Linux -> window buttons in general:<br>
> On Gnome it's actually pretty rare to have three buttons at all.<br>
> maximised is done via double click on the header, leaving<br>
> minimizing and closing. But I can't change the visibility (or<br>
> order) of the buttons.<br>
> Additionally, native buttons can be configured in which order<br>
> (and on which side) they are. I don't know if the current<br>
> implementation takes that into account.<br>
<br>
The current implementation does not take a custom button order into<br>
account, and there is no API to change the button order or visibility.<br>
This might be a future enhancement.<br>
<br>
By the way, if you don't want the default buttons, you can pretty<br>
easily bring your own buttons instead (see the documentation of<br>
StageStyle.EXTENDED). If you own the buttons, you can change order and<br>
visibility as you like.<br>
<br>
<br>
[0] <a href="https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09" rel="noreferrer noreferrer" target="_blank">https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09</a><br>
[1] <a href="https://mail.openjdk.org/pipermail/openjfx-dev/2024-October/050141.html" rel="noreferrer noreferrer" target="_blank">https://mail.openjdk.org/pipermail/openjfx-dev/2024-October/050141.html</a><br>
</blockquote></div>