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.

Has there been any other movement on this? It was a jarring and rather annoying discover for me to find that I couldn't force the titlebar and borders onto certain applications like Firefox, Discord, and EasyEffects, all of which are GTK Wayland windows, right? 

(In reply to Roke Julian Lockhart Beedell from comment #10)
> 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. 

That is *precisely* what happened to me and one other individual I was discussing this with.  I wish there was at least some kind of tooltip or something that says "Removing titlebar and border works on Wayland, but forcing the addition of does not."

I wish I could just force it and deal with the weird applications anyway. Forcing an override for something like window decorations seems like a thing people should expect to cause wonkiness, at least to me.  Honestly I'd force the change for myself, but I'm not sure where to look. I'll be doing my own research but if someone would be kind enough to point me in the right direction it'd be much appreciated.

David, I reiterate: can we at least have the option on Wayland? It already forces a gap on XWayland, and I don't mind it doing so, regardless. (Do novice users really go around enabling random window decorations?) If so, let's consider this from the perspective of a pure Plasma user; without https://bugs.kde.org/show_bug.cgi?id=476996#c17, I am reminded of the fact that I can't force window decorations every time I utilise Plasma Shell on Wayland. Even beyond that, not being able to invoke Alt + F3 on touch-screens means that I've lost significant functionality, due to the shell's poor SSD reimplementation of what KWin already provides. 

This is literally the sole regression that incentivises me regret KWin's transition to Wayland. It was the feature that convinced me to try Plasma over GNOME, when I first switched to Linux! (Not that I'd go back.)

(In reply to Roke Julian Lockhart Beedell from comment #19)
> David, I reiterate: can we at least have the option on Wayland? It already
> forces a gap on XWayland, and I don't mind it doing so, regardless. (Do

We changed kwin recently so SSDs can be forced for Wayland windows.

Regarding FF, there's literally an option to make it use system titlebar.

> novice users really go around enabling random window decorations?) If so,
> let's consider this from the perspective of a pure Plasma user; without
> https://bugs.kde.org/show_bug.cgi?id=476996#c17, I am reminded of the fact
> that I can't force window decorations every time I utilise Plasma Shell on
> Wayland. Even beyond that, not being able to invoke Alt + F3 on
> touch-screens means that I've lost significant functionality, due to the
> shell's poor SSD reimplementation of what KWin already provides. 
> 
> This is literally the sole regression that incentivises me regret KWin's
> transition to Wayland. It was the feature that convinced me to try Plasma
> over GNOME, when I first switched to Linux! (Not that I'd go back.)

> Regarding FF, there's literally an option to make it use system titlebar.

However there are situations where one may want to use Firefox's client-side titlebar and still force SSD decorations. With an Aurorae theme that allows you to disable the titlebar but keep the server-side border (for example Klassy), by doing this you can get Firefox's CSD while using KWin's server-side window border, which behaves in a much more stable way than Firefox's.

The same goes with Chromium.

(In reply to Vlad Zahorodnii from comment #20)

> We changed kwin recently so SSDs can be forced for Wayland windows.

Thank you! Do you happen to know what version that's in (or, if not, the relevant commit, so I can ask at Discuss)? I ask because, in `6.5.3`, `noborderrule=2` doesn't appear to apply to `plasmashell`, etcetera.

We should also change the closure status to FIXED, rather than INTENTIONAL, if so.

I read back over my earlier comment and I apologize for its tone. I didn't intend for it to sound so impatient and rude. I'll do better. 

(In reply to Vlad Zahorodnii from comment #20)
> We changed kwin recently so SSDs can be forced for Wayland windows.

That's awesome! Thank you! I totally missed it earlier when I was digging. 

(In reply to Roke Julian Lockhart Beedell from comment #22)
> Thank you! Do you happen to know what version that's in (or, if not, the
> relevant commit, so I can ask at Discuss)?

Looks like it's planned to be released in 6.6.  Here's the merge request: https://invent.kde.org/plasma/kwin/-/merge_requests/8529

According to the schedule we can expect it sometime around February: https://community.kde.org/Schedules/Plasma_6#Future_releases.

Thank you so much, Vlad Zahorodnii and Xaver Hugl! Your work is appreciated.

> Thank you so much, Vlad Zahorodnii and Xaver Hugl! Your work is appreciated.

I concur. Changing to FIXED.