Created attachment 164656 [details] https://flathub.org/apps/com.quexten.Goldwarden (id=455195#c7) SUMMARY The native window border renders far past boundaries of GTK 3/4 window border when noborderrule is set to 2 (Force Always). STEPS TO REPRODUCE 1. Create a KWin Rule. 2. Set "No titlebar and frame" to "On" + "Force" (noborderrule=2) 3. OBSERVED RESULT The native window border renders far past boundaries of GTK 3/4 window border. EXPECTED RESULT The native window border should render around the GTK window border as it used to (or better yet, replace it, but that's infeasible and an FR anyway). SOFTWARE/OS VERSIONS Operating System: cpe:/o:opensuse:tumbleweed:20231226 KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.113.0 Qt Version: 5.15.11 Kernel Version: 6.6.7-1-default (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 7600X 6-Core Processor Memory: 30.5 GiB of RAM Graphics Processor: AMD Radeon RX 5700 Manufacturer: ASRock Product Name: X670E Taichi ADDITIONAL INFORMATION See the https://bugs.kde.org/page.cgi?id=fields.html#see_also of this bug.
(In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #0) > Created attachment 164656 [details] > Depiction of the problem. (id=455195#c7) > > SUMMARY > > The native window border renders far past boundaries of GTK 3/4 window > border when noborderrule is set to 2 (Force Always). > > STEPS TO REPRODUCE > > 1. Create a KWin Rule. > 2. Set "No titlebar and frame" to "On" + "Force" (noborderrule=2) > 3. > > OBSERVED RESULT > > The native window border renders far past boundaries of GTK 3/4 window > border. > > EXPECTED RESULT > > The native window border should render around the GTK window border as it > used to (or better yet, replace it, but that's infeasible and an FR anyway). > Note that this used to not be an issue, recently. It was a regression introduced approximately 1 year previous.
Created attachment 164658 [details] https://flathub.org/apps/com.protonvpn.www https://github.com/ProtonVPN/proton-vpn-gtk-app, not https://github.com/ProtonVPN/linux-app.
Created attachment 172395 [details] Padded border with duplication: flathub.org/apps/com.quexten.Goldwarden (bugid=455195#c7)
Created attachment 172396 [details] Padded border without duplication: flathub.org/apps/com.protonvpn.www
Created attachment 181433 [details] A Screenshot Of gnome-abrt-1.4.3-4.fc42.x86_64 With Artifacts When Screenshotted Via Spectacle's "Full Screen" Mode
Created attachment 181434 [details] A Screenshot Of gnome-abrt-1.4.3-4.fc42.x86_64 With Duplicate Decorations (GTK3 CSDs And Breeze SSDs) This reproduces on: > Operating System: Fedora Linux 42 (KDE Plasma Desktop Edition) > KDE Plasma Version: 6.3.4 > KDE Frameworks Version: 6.13.0 > Qt Version: 6.9.0 > Kernel Version: 6.14.5-300.fc42.x86_64 (64-bit) > Graphics Platform: X11 > Processors: 6 × AMD Ryzen 5 7600X 6-Core Processor > Memory: 15.6 GiB of RAM > Graphics Processor: llvmpipe > Manufacturer: QEMU > Product Name: Standard PC (Q35 + ICH9, 2009) > System Version: pc-q35-9.2
Comment on attachment 181433 [details] A Screenshot Of gnome-abrt-1.4.3-4.fc42.x86_64 With Artifacts When Screenshotted Via Spectacle's "Full Screen" Mode This is out of scope for this: it's handled by https://bugs.kde.org/show_bug.cgi?id=455195#c13.
Created attachment 181437 [details] A Minimal But Reproductive Exported ".KWinRules"
Created attachment 181439 [details] An (Example GTK 3) Screenshot Of gtk3_preview From kde-gtk-config-6.3.4-1.fc42.x86_64 Without Duplicate Decorations
Created attachment 181440 [details] An (Example Qt 6) Screenshot Of drkonqi-coredump-gui From plasma-drkonqi-6.3.4-1.fc42.x86_64 Without Duplicate Decorations
We should just get rid of this option if it doesn't work reliably.
(In reply to David Edmundson from comment #11) It works *reliably*, for it always draws SSDs. However, around GTK3 applications, it draws more than it should. A visual bug is indeed bad, but it's a regression, so it should be possible to remediate.
(In reply to Roke Julian Lockhart Beedell from comment #12) > (In reply to David Edmundson from comment #11) > > It works *reliably*, for it always draws SSDs. However, around GTK3 > applications, it draws more than it should. A visual bug is indeed bad, but > it's a regression, so it should be possible to remediate. Actually it seems to me that it only happens with GTK4 applications (I've tried Nautilus/GNOME Files, GNOME Calculator and GHex), but *not* with GTK3 applications (I've tried GEdit, Evince, Cheese and Firefox when it uses CSD). It also happens with Chromium when set to use CSD, even though it depends on Qt and not GTK (Idk if it got ported to fully use Qt, or perhaps it's statically linked to some GTK version while also using Qt for some purposes). Also, KWin seems to be aware of it: for the GTK4 ones, the "No titlebar and frame" option is already disabled in the context menu (at least on X11), and it can only be forced from the special window settings, while for the GTK3 ones it's available in the context menu.
Also, KWin seems to know where the actual window begins and ends in the case of these GTK4 windows, as window snapping works as expected when no SSD is forced on them (unless that's also done by the client in the case of CSD windows), so in principle it should be feasible for KWin to cut off that area around the actual window when SSD is forced on the window.
(In reply to Grósz Dániel from comment #13) All the screenshots attached depict GTK 3 applications. If you cannot reproduce it on those examples, that may be of interest. In https://bugs.kde.org/show_bug.cgi?id=389495, it is demonstrated that GTK ≥ 3 is able to request SSDs for an application, so you may merely have located examples of such GTK 3 apps and be comparing them to GTK 4 applications that utilise Libadwaita (which is not unanimous). Irrespective, ⪆ provides both a GTK 3 and Qt (5 or 6, IDK) backend, switchable at chrome://settings/appearance#:~:text=Appearance, for its chrome.
(In reply to Roke Julian Lockhart Beedell from comment #15) > All the screenshots attached depict GTK 3 applications. If you cannot > reproduce it on those examples, that may be of interest. In > https://bugs.kde.org/show_bug.cgi?id=389495, it is demonstrated that GTK ≥ 3 > is able to request SSDs for an application, so you may merely have located > examples of such GTK 3 apps and be comparing them to GTK 4 applications that > utilise Libadwaita (which is not unanimous). I'm not sure, I just noticed that of the few applications I tried, all the ones where I could reproduce the bug depend on GTK4, and the ones I couldn't reproduce it depend on GTK3. I managed to install Goldwarden from flatpak, and I can reproduce the bug; I've no idea how to check what GTK version it uses: flatpak only tells me it depends on org.gnome.Platform/x86_64/47, which I assume contains both GTK3 and GTK4. I'm not sure what it means for an application to request SSD for itself; the ones I couldn't reproduce the bug with still have a CSD and no SSD by default, until I force an SSD on them in the context menu or the special window settings. Also, Idk if requesting an SSD for itself is a thing on X11 (which I use); the other report seems to mainly discuss Wayland. I've tried a few applications that use GTK4 but not libadwaita. Some of those actually have an SSD by default on KDE, and it looks fine, but the ones that have a CSD by default reproduce the bug when an SSD is forced on them. > Irrespective, ⪆ provides both a GTK 3 and Qt (5 or 6, IDK) backend, > switchable at chrome://settings/appearance#:~:text=Appearance, for its > chrome. I see that setting, but I think it only sets which toolkit it takes its color scheme from, not which toolkit it actually uses to draw itself. The colors change immediately, and I doubt it could switch backends on the fly without even a flicker. It also offers "Classic" as a third alternative to Qt and GTK.
(In reply to Grósz Dániel from comment #16) I'll acquiesce on all points. Thanks for the investigation. BTW, I meant to write "⪆ chromium-137.0.7151.68", but somehow forgot to paste before submitting the comment. > I've tried a few applications that use GTK4 but not libadwaita. > Some of those actually have an SSD by default on KDE, and it looks fine For the sake of comprehensive screenshots, what GTK 4 applications *did* you locate that requested SSDs? Currently, I've confirmed that the GTK3 Preview, spawned from `kcm_style`, does. However, that'll be irrelevant once GTK 3 becomes deprecated in practice.
Created attachment 182102 [details] HandBrake (uses GTK4 but not libadwaita), using SSD on the main window but CSD (and glitching when an SSD is forced) on its dialogs (In reply to Roke Julian Lockhart Beedell from comment #17) > For the sake of comprehensive screenshots, what GTK 4 applications *did* you > locate that requested SSDs? Currently, I've confirmed that the GTK3 Preview, > spawned from `kcm_style`, does. However, that'll be irrelevant once GTK 3 > becomes deprecated in practice. pavucontrol and freeciv-gtk use SSD. HandBrakeGUI uses SSD on its main window, but it uses header bars on dialogs, and they glitch when an SSD is forced on them.
GTK4 apps that use SSD by default under KDE also have rounded corners at the top, below the SSD title bar, as can be seen on the main window on my HandBrake screenshot, which is a bit ugly, but much less of a problem than the wide, glitchy area between the window and the SSD in the case of forcing SSD on some GTK windows (in my experience, GTK4 ones)that use CSD by default. I don't see this corner on GTK3 apps that use SSD, such as Inkscape, GIMP, Firefox, VS Codium (the latter two when configured inside the app to use SSD) etc.