Whilst waiting for noborderrule=2 (enforced SSDs) to be implemented for kwin-wayland, today, blueman-2.4.6-4.fc43[1] produced a CSD window without any window action buttons visible:
If I were using a tablet (without right-click or F3), I would need to utilise the shell to close these. Instead, I shall note that AOSP 15 always enforces SSDs for such windows, which KWin should replicate.
I shall be surprised if KWin were unable to know whether a window renders closure buttons.
#!/usr/bin/env sh
rpm -qf $(command -v blueman-applet)
The whole point of CSDs is that they are part of the application’s normal output.
For the compositor is it essentially just a rectangular buffer of pixels.
The app can put the window actions anywhere it wants, only have some or none at all.
The compositor could of course provide some for of UI or user action to force decorations around any such client buffer or close the window, etc.
On a touch device it could, for example, understand gestures for window actions, etc
@krake, that’s basically what kcm_kwinrules exposes. I feel that it being so unintuitive is a shame, however; I doubt that most users shall ever access that KCM. If, the first time a CSD window appeared, a dialog would appear, to inform the user why the standard window decorations are absent, that would be wonderful.
Yes, such an override would likely end up as a window or application rule, however in terms of UI I was thinking more like mouse/touch/pen gesture to bring up the window menu the way F3 does, maybe with an additional toggle option in that menu for windows with CSD to force enable SSD.
I think that would be too annyoing.
Most windows with CSD do have at least minimize/maximize(close actions and often in very “common” designs.
Some of them, e.g. Chrome, even have nice options in their “title bar” to enable “system title bar” to switch to SSD, which is even better than having decorations twice.
