I think it would be nice to overlay server side window decorations on the app chrome, similar to how it’s done on Mac with NsWindow, where the compositor and application negotiate ownership over the titlebar area. The result is that decorations can look entirely consistent with both the application goals and the system style.
Take a look at this app. The ssd strip seems superfluous and clashes with the application. As long as the server draws a cookie cutter stip on top the app, these problems are going to persist.
I’m not going to bother doing a mockup because I trust everybody knows how it would look on mac os: the artwork area would be extended all the way to the edge of the window and the traffic lights and transparent drag area would be overlayed on top of it. The usual counterarguments are that you’d lose the title, but in the case of this app - where the entire top region prominently displays the song you’re playing - who in their right mind wants to read the title off the titlebar? I think most people would be happy to dispense with redundant info in order to save screen real estate and get significantly more elegant-looking applications.
Or look at a typical Kirigami application:
It tells you “Keyboard” four times, with the toolbar strip positively screaming KEYBOARD. What purpose does the dedicated titlebar serve here? To inform the user, for the fourth and final time that this window pertains to keyboards? If the titlebar were merged with the toolbar area, absolutely nothing of value would be lost. The UI would just look smarter and vertical screen real estate would be saved.
Another problem this would solve is the fact that on KDE, the toolbar and titlebar are visually merged. Hover they aren’t functionally merged. You can’t double click the toolbar area to maximize the window. Dragging isn’t guaranteed either. But since the toolbar and titlebar aren’t delineated, the user isn’t really sure where he is supposed to click in order do window management. A few pixels too low and you’re not in the titlebar area anymore. This proposal would get rid of the problem completely.
Third and final bonus to doing this is potentially better stylistic integration on other desktops and OS’ where some merger between titlebar and app chrome is now standard, and it is traditional titlebar apps that now “look out of place”. If you can set aside space for Kwin to draw decorations, you can potentially use that space - further down the line - for NsWindow type decorations on Mac Os. You could also use that space to draw true CSD on Gnome. If you slap a libadwaita theme on there too, you’d get essentially native-looking KDE apps on Gnome, improving adoption beyond KDE.
So to sum up potential benefits:
- Less redundant info
- Saves vertical space
- Greater visual consistency within the application window (e.g. no unintended visual mismatches between application and titlebar)
- Arguably easier and more predictable window management experience over current behavior.
- Can lay groundwork for better UI integration on other desktops down the line.
- Potentially make non-QT apps look and feel much more native on KDE (with user or other third party intervention, as explained below)
To implement this, apps would need to define a draggable area and set some space apart for the system min/max/close buttons. For a traditional app with menubar, it should be relatively trivial: just set the entire menubar area as drag space and leave space in the corners (which is almost always empty anyway) for the WM buttons.
For the vast majority of QT apps I suppose this could even be done entirely through the theme engine, without any modification to apps. That’s not to say to that it should - matter of preference - but it could.
This could even be accomplished without any support from the app whatsoever - again, not to say that it should necessarily but it could - you could just overlay a transparent title-bar on the entire menu-bar, shove the title and WM buttons in the free space on the right, set a rule saying “window title+buttons cannot encroach on the menubar beyond x window width , and call it a day. This same approach could be used to reliably overlay KWin min/max/close buttons on applications that insist on drawing their own. Right now Gnome apps draw their own WM buttons but use the breeze icon theme (I think) to render the actual glyphs on kde. The result doesn’t look like KDE or Gnome - it just looks broken. Simply overlaying the ssd controls over the native ones, behind the apps’ back would actually be preferable to the status quo in this case. KDE also does some complex wizardry to make breeze-style WM buttons on GTK3, would simply painting over them really be worse? Maybe yes maybe no, rational people can disagree I suppose.
There’s ample prior interest in putting “something” into the menubar from KDE community. Locally integrated menus have been discussed for some time and are apparently going to be officially part of future plasma desktop releases. Others have proposed solutions that are essentially identical to what I’m proposing here in more (perhaps too much 
) detail.
Apparently this has already been proposed by somebody for wayland but the issue has stalled. I think the way to move forward on it would be to implement something on KDE first. Otherwise it’s just going to be arguments about maybe doing something with Gnome people saying “we won’t do it” other people saying “you should do it” and them saying “no we won’t” and so on, and it will just peter out there. But if NSwin style decorations can be shown to work on KDE in a way that people like, it should generate enough interest for other compositors to want to do the same. And if there’s enough interest from projects it could eventually become a wayland extension in a couple years - worth it IMO because without this is there won’t be any consistent window management ever.
