Bug 452240

This isn't as doable on wayland as it was under X11. The GTK clients will behave differently. We can force a deco, but it'd have a massive margin and then the window contents. 

Your best bet is to complain to upstream for not supporting the proper standards.

Created attachment 164623 [details]
Response to #c1.

(In reply to David Edmundson from comment #1)
> This isn't as doable on wayland as it was under X11. The GTK clients will
> behave differently. We can force a deco, but it'd have a massive margin and
> then the window contents. 
> 
> Your best bet is to complain to upstream for not supporting the proper
> standards.

Like this?

*** Bug 470535 has been marked as a duplicate of this bug. ***

(In reply to Nate Graham from comment #3)
> *** Bug 470535 has been marked as a duplicate of this bug. ***

I strongly believe this needs to be reopened, because what kde@davidedmundson.co.uk explains in https://bugs.kde.org/show_bug.cgi?id=452240#c2 is now what occurs (as demonstrated by https://bugs.kde.org/show_bug.cgi?id=479372#c1) which means the stated thing to prevent being the reason for closing this as intentional has already come to pass. However, this is also the sole issue keeping me on X11 — it's also *the* reason I initially chose to use KDE Plasma, because differentiating between Windows was impossible in Windows. It's an incredibly important accessibility feature for me.

(In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #4)
Another example of where this is problematic is https://wiki.archlinux.org/index.php?title=Talk:DaVinci_Resolve&oldid=806169#c-RokeJulianLockhart-20240416163900-noborderrule=2_doesn't_work_on_Wayland.

I'm also affected by this bug. I don't care about the additional margin between the window and the server-side decoration, as this is mostly an accessibility feature, and also that border can be removed by the user with some GTK CSS.

(In reply to Mattia from comment #6)
> that border can be removed by the user with some GTK CSS.

Can you share that CSS? That might help to fix https://bugs.kde.org/show_bug.cgi?id=479372#c1.

At the moment I've added this to my ~/.config/gtk-3.0/gtk.css and it works for GTK3:

decoration, headerbar.titlebar {
    border-radius: 0;
    box-shadow: none;
    margin: 0;
}

I guess the same will work with GTK4. In any case, this is something that the user needs to do – I don't think KDE should change the CSS for GTK apps. Nevertheless, I don't feel like this issue is enough to not implement noborderrule=2 altogether.

An addendum: even if it is decided not to implement this feature on Wayland, the "No titlebar and frame" option should at least be hidden from the Alt+F3 menu. At the moment it is shown, but has no effect.

(In reply to Mattia from comment #8)
(In reply to Mattia from comment #8)
> Nevertheless, I don't feel like this issue is enough to not implement noborderrule=2 altogether.

Especially because a user can still choose the option, and it's applied, but merely to XWayland applications. That must be confusing for anyone who hasn't located this ticket.

> In any case, this is something that the user needs to do – I don't think KDE should change the CSS for GTK apps.

Do you mean specifically in this manner? If so, why? Otherwise, surely you're aware that they modify the CSS when they apply the GTK theme (since it applies to GTK4 too).

> Do you mean specifically in this manner? If so, why? Otherwise, surely you're aware that they modify the CSS when they apply the GTK theme (since it applies to GTK4 too).

Applying the theme is one thing, applying some specific CSS rules only to windows which have "No titlebar and frame" forced to "off" would be much more strange (especially since this would have to be triggered by KWin itself) and I don't even know if it's possible. You'd have to detect if the application you're acting on is a GTK app and you'd have to find a way to set CSS rules on a specific window only.

Either way, again, I still think this feature should exist on Wayland. It's the user's responsibility if enabling it ends up looking bad for specific apps.

(In reply to Mattia from comment #11)
> Either way, again, I still think this feature should exist on Wayland. It's the user's responsibility if enabling it ends up looking bad for specific apps.

There is the reasonable expectation that a feature shouldn't be "broken" per se, but because it's purely cosmetic, as long as https://bugs.kde.org/attachment.cgi?id=172395&action=edit is fixed, I can't see *any* reason to disagree - it's a few cm of accidental window padding for an accessibility feature.

And also it works on X11 and has the same issue there...

(In reply to Mattia from comment #13)
Yeah! It should really be consistent, at least.

Comment on attachment 164623 [details]
Response to #c1.

(In reply to Roke Julian Lockhart Beedell from comment #2)

> Like this?

Going to obsolete that attachment, and link to https://bugs.kde.org/show_bug.cgi?id=479372 instead.

(In reply to Mattia from comment #13)
> And also it works on X11 and has the same issue there...

Yes, it (a glitchy area between the actual window and the forced SSD) happens on X11 too with some GTK apps. And, at least on X11, KWin knows where the actual window begins and ends for the purposes of snapping, so in principle it should be able to cut off the shadow when an SSD is forced on the window (unless I'm mistaken and snapping is also done by the client in the case of CSD apps).

What's annoying is that the issue with GTK apps is being used as a reason to disable this feature altogether on Wayland, for all applications, and I don't quite understand why that is. This sounds like a pointless feature, but it's actually really useful in certain situations. My use case is the following: I want Chromium to have server-side decorations while still showing its own window controls, so that I can then hide the server-side titlebar via Klassy, but still keep the server-side window border, which is much better than Chromium's. Same goes with Firefox.