Now, KDE apps typically do not use client-side-decorated headerbars for their header areas like GNOME apps do. Instead, we generally hew to the traditional arrangement of a titlebar, menubar, and toolbar. The titlebar is “server-side” because it’s drawn by KWin, our window manager. Everything below the titlebar–such as the window’s menubar, toolbar, and content view–are drawn by the window itself; the window being a “client” of the window manager. Hence, “client-side”.
KDE’s approach is so much better and more sane than the CSDs in GNOME. CSDs have wreaked havoc in the world of GTK desktops, with Xfce in particular suffering hard due to its use of Xfwm, causing a giant rift between the looks of Xfwm and the CSDs of many GTK applications. The main issue here is that a title bar is a title bar for a reason – I don’t want it littered with buttons and other widgets that belong to the application, not the window.
I guess I’m just getting old.
I must be getting old do. Sure, it can look aesthetically pleasing, but god damn UI usability has taken a nosedive in the past decade.
Decades of UI usability is now just completely ignored in order to make an app visually attractive. And it isn’t even that hard to get things right! It just takes a little time spent caring about it.
Interestingly I think Google is in a great position to enforce good usability, at least in webpages. Pages designed for usability should rank higher in Google’s search results than otherwise.
I agree, and in fact Google already claims to do this: https://www.google.com/search/howsearchworks/algorithms/ (click the “Usability of webpages” tab).
Of course, their understanding of usability may not be the same as yours or mine. The fact there’s no easy way to link to the content in the “Usability” tab on that page is a usability fail in my book 😉
Chalk me up for getting old too.
At least Arch has a patched gtk3-classic package, PCMan of LXDE/LXQt produced a gtk3-nocsd package for Debian-family distros which installs a system-wide LD_PRELOAD to forcibly disable CSDs even if an app is too GNOME to accept being asked to do without header bars, and the GNOME ecosystem’s enthusiasm for Flatpak is getting things migrated to GtkFileChooserNative, which KDE’s XDG Portal host can override with KDE file choosers.
(Electron just merged a patch a month ago so it should be using GtkFileChooserNative starting with v14.)
…and, of course, KDE offers GTK 2 and 3 versions of its Breeze theme, which helps.
It’s for exactly this reason that I stick to Qt these days and the only GTK application I maintain has no GUI and would be Qt-based if Qt had an equivalent to libwnck.
Another one getting old…
It’s a shame there’s no middle ground here. I’m strongly of the belief that window decoration should be server-side and system-controlled for consistency. On the other hand, title bars are generally a bit of a waste of space and I’m all for new and innovative approaches. I was never a BeOS/haiku user, but using little stackable tabs instead of a title bar looks like a really nice idea (perhaps an “old and innovative” approach?)..
Ironically, having client-side decoration also means there’s less scope for system-wide innovation.
I don’t like having things show through behind a not-full-width tab, but WM-level tabbing is a useful idea if you remedy that by making it more like how dragging tabs between browser windows works, but with no maximum tab width.
KWin from KDE 4.x had that near the end of its lifecycle and it copied the idea from Fluxbox which had its last stable release in 2015 but is still packaged for various distros.