KDE Still Isn't For Client-Side Decorations But Has Been Selectively Using Some D.W.D.

[idash]

Yet again, trying to make people confused between header bars and CSDs, which are not the same thing. Although the former requires the latter.

Pretty much all the criticisms of CSD's in that blog post are criticisms of header bars, not CSD. Windows and macOS (and even some GTK apps) have normal title bars with CSD.

Yeah, I'm not sure why even developers and people who are supposed to know better keep using "CSD" and "Headerbars" interchangeably.
I use Wayfire, and by default ALL native Wayland applications use CSD, yet most of them still have a normal title bar and a menu bar.

Please use the appropriate word, because otherwise it's just confusing. Every time a I read "CSD", I have to figure out whether the writer means actual CSD in general, or specifically header bars.

[zxy_thf]

And a note for KDE fans, CSD does not mean Gnome CSD, it means that not two but one party is responsible for drawing the Windows. There is nothing that would stop KDE apps from drawing decoration that looks and works exactly as the server side decoration KDE uses. In fact if you used a KDE app on a gnome desktop, you already used KDE apps with CSD. For the usual known reason, those CSDs don't bug out on Gnome.

To be frank I never see the point of CSD vs SSD.

Even in the X11's SSD days, there is nothing stopping the application from requesting a borderless windows and do whatever it wants, making the application effectively CSD (like lots of games).

On Windows such kind of apps was already widely spread even before the proposal of Wayland (or even the word "App" itself).
The earliest one I can remember dated back to VB6 days.

Ultimately it's up to the app to comply with the decoration policy since the beginning. I really can't see the reason forcing SSD and then pretending app won't do the other way.

[ngraham]

The process has started. So when are we getting the inevitable “How I learned to like CSD” blog post? My guess is late 2022.

lol no

[billyswong]

My KDE title bar includes Close, Max, Min, Roll up/down, and show on all desktops. When multitasking all those are handy so it's a bit annoying when they're buried in a menu somewhere. It used to include the ? help function. The problem is that most of the time I've used the ? for help it was basically as helpful as a tool tip. If the tool tip was helpful I wouldn't have used the ? thingy. It's a catch 22.

The situation is worse than "buried in a menu somewhere". A CSD program, no matter it is headerbar-style or not, is very likely missing your "roll up/down" and "show on all desktop" feature because they are not KDE-native and didn't think of there would be such thing when developing. You probably need to access them outside the window, for example by right-clicking on the corresponding window entry in taskbar, but such seeking would defeat the purpose of "roll up/down".

I hated how every version of Windows I used before I left Windows XP for Mandrakelinux 10.0 would have its titlebars go non-responsive when the application's message loop got bogged down in certain ways, while I've never had X11 suffer from that problem.

I wonder if we could overlay a "server side region" that can override those CSD windows. Such region will cover the whole titlebar or at least the min/max/close buttons region of those header bar. If implemented, within such region, dragging the window will always work even for hanging / unresponsive window. A right click will produce a server side menu that will always provide all options provided by the windows manager.

Unless some software want special non-window-management function hidden in right-click of min/max/close, I guess such override won't break anything?

[lumks]

Sad that KDE doesn't let the user choose to turn on/off CSD.

[ElectricPrism]

We now live in an age where 1366x768 is thankfully near death. Vertical pixels are not as precious. Even if they were a left-hand title bar and window controls was still damn cool and smart compromise with horizontal pixels to spare on the shitty 16:9 aspect ratio.

I don't mind KDE standing up for what they believe in, at the very least I want the choice to opt-out of CSD. Having used CSD in other shells it seems like window controls triggering the appropriate actions can go unresponsive which is honestly ridiculous.

I prefer keeping Title Bars because similar to "prime numbers" I don't believe that you can continue to simplify beyond a certain limit and obfuscating software UX.

TL;DR; Simplification Good. Oversimplifying Bad.

Genius Simplifies. Ignorance Complicates.

[Kver]

So, for those who can't recall I'm the original author of the whole DWD thing. I can't bring myself to particularly care about defending the concept anymore, but I do have some thoughts on the post;

They would either lose a lot of space used for dragging the window, or else lose the ability to click-and-drag-and-release to activate headerbar items in menus, comboboxes, pop-up menus, etc. You can’t have both with CSD headerbars.

This is a real race-to-the-bottom view of putting controls in the title area, and it works on one supposition; that dragging windows around is the most important aspect of an application. From the perspective of a WM developer then, yes, you'll want the WM to shine. From the perspective of the app developer you may want fewer rows in your application interface.

The simple fact is heasderbars are a tool in a toolbox. One of many things a designer can use. This argument is essentially telling the application designers they aren't responsible enough to use that space. I don't believe basic KDE applications should be limited in the tools they can use because the potential misuse might occur. I nearly hit the point of developing a CSD library for KDE before I just lost all motivation. I mean, imagine if radio boxes were banned from all applications, their implementation removed, because some apps might abuse them? This is the same thing.

Can we not do something crazy like have a sliver of padding? Can we not enforce some small spacers between widgets? Do we have so little control over our own software we have to assume some moron filling the title region with a bar graph must bury the concept before investigating?

There's absolutely no reason why putting widgets into the title region can't be done responsibly, but when I hear things like "over my dead body" it's really just the death of innovation there. For applications having the option to compact the interface cleanly will lead to a better experience. There's 0 trust in the designers to do much more than re-paint the theme.

If I recall correctly, even Kirigami is designed in a way that enforces several design choices on a technological level. Even the Kube developers years ago nervously acknowledged the rigidity and why aspects (at least at the time) couldn't use pure Kirigami.

There would be no place to display the name of the app, window, or open document–unless the app left a big empty space in the middle of the header for it. Even then it would be up to every app to implement this title itself, rather than it being an automatic thing provided by the window manager.

This is something already abused in the opposite direction, doubly so in the Kirigami applications. Open Discover and maybe click "Applications". There's... 3 labels. There's the label in the title, label in the app-side title, and label in the search box. When I first saw this I wondered if there's a label-maker enthusiast who has a sticker on his shirt that says "shirt".

When I open Firefox I don't suddenly get confused about which app I'm looking at. If I open a calculator it's obvious what it is. Again, and I'll hit this point with a sledgehammer; KDE developers need to have some trust that app designers will do the right thing, or at least work together to find the right balance. I don't need my video player to tell me I'm watching Monty Python in the titlebar. I don't need my calculator to always remind me it's a calculator. Dolphin very kindly dedicated it's location bar to showing where I am; the title region could be used for a tab bar. The new System Monitor has the page in the title, the second bigger title, and highlighted in the sidebar... Users are not so lost that they need 3+ reminders of the page they are currently looking at. Two would do!

On that point, go into Systemsettings and click "Workspace behaviour". Follow the titles, highlights, and labels! Workspace > Workspace Behavior > Workspace Behavior > General Behavior > General Behavior > General Behavior > System Settings. Tell me there isn't over half a dozen labels telling you where you are, and tell me the title is truly necessary. Above the sidebar is a hamburger, home, and search bar. Put that in the title region, ditch the extra title row, and nothing of value is lost, but the application gets to look cleaner. Overcrowding is just as much a problem as oversimplifying.

We would probably have to remove or severely restrict how customizable the toolbar can be given the above restrictions on space.

This is working under the assumption that whatever gets shunted into the title area is a toolbar. It doesn't have to be. Any horizontally expanding widget is a candidate to go in the title region. Search bars, tab bars, menu bars, progress bars, name it. KDE does not need to just make "Gnome Qt", again, speak with designers, see what the devil they want, and maybe DWD or my old client micro-deco-server designs could make better use of that space. And you know what? If they want something stupid maybe help them anyway, because sometimes stupid ideas pave the road to good ones. Perfection is the enemy of good.

It also works under the assumption that CSD-like controls are enforced. They don't have to be. Right click on a window -> "Always show titlebar". Suddenly everyone gets what they want; designers can get a cleaner interface, and people demanding WM-native controls get what they want.

Also given the above restrictions, the CSD headerbar would probably have to omit some of the window decoration buttons currently present on the SSD titlebar, since they would be taking up a lot of space that apps would need. Customization flexibility would also be reduced.

This is one thing I'm very sad was lost somewhere; a fully decked-out SSD might only have 100-150 userspace pixels of width dedicated to WM buttons if literally every button was present. Again, and again and again, 0 trust in the designers here. You're working under the assumption that the goal is to shove an airplane cockpit into the title region.

Would you not see two more lines of text in Kate if *just* the tab bar was moved up? Or even the menu bar? Dolphin might enjoy tabs or an omnipresent search box in that region. Does the new system monitor have *so much* in its header that it wouldn't work? Do I need to see "Kamoso" because the 5 buttons in the toolbar wouldn't fit? Are we going to force Dolphin to use a headerbar because it's cool? No!

And again; we don't need to be Gnome here and make *everything* use headerbars. Designers can look, see what's appropriate, a HIG can be thought out, and a toggle can be put in. Plasma and KDE stuff has always leaned on the more advanced and "pro" grade of the user spectrum, using open real estate doesn't mean we need to dumb-down the UI, it just means we can tidy up other portions of the UI.

Windows would all have to have hamburger menus with no provision for a traditional in-window menubar, since there is nowhere to put one in a CSD headerbar without it looking really weird.

No. Again, you're only looking at what Gnome is doing, and again, you're making decisions for the designers. Not every app has a menubar, not every app has *so many* controls, and not every app needs to treat the title region as a toolbar.

Better yet, this is an implementation detail. Why couldn't KDEs equivalent not take on firefox-like behavior, where the Menubar takes precedent in that region when enabled? We were never bankrupt of good ideas, yet when the conversation moves to headerbars all people can think of is the Gnome implementation. Is there no new, original, unique idea to push the UI further?

When a window is not responding, the close button would not work to force-quit it, since it would be drawn by the thing that is not responding (the window) rather than a thing that is still working (the window manager)… unless the window manager itself implemented a hack for this. So it would not work in other window managers.

I had a very flexible non-hack solution to this. I was told it would cost something like 20MB/window then was shot down. I'm certain with Wayland now the costs might be negligible. Frankly, whenever I wore my design hat in KDE I was shot down from 37 angles because there was 0 trust in the designers to use the space responsibly no matter how many hurdles I cleared on the tech level.

It would suck for people using our apps on other platforms without window manager level support for CSDs.

The final frustration, every. single. implementation. I. proposed. was. user. toggle-able. and. backwards. compatible. Gnome may have kicked the dog for other platforms but we can be smarter.

...

I love KDE and Plasma. It ain't perfect, it's got issues, and nobody in their right mind wants to introduce more avenues for bugs. At the same time Gnome gave headerbar style controls a really bad impression because they rushed the implementation and it literally hurt the entire Linux desktop ecosystem... So now developers have their heads in the ground because one group did it badly, so the whole concept is wrong. WM developers are so eager to cite 37 ways the titlebar might be slightly-less-good, that they ignore every other way applications as a whole could potentially be better.

I will never forget the two hours I got to work with David Edmonston in, I think it was my second sprint. I had him ripping his eyes out, but he was a solid trooper, hats off to the man. I managed to convince him to get *one* control into the titlebar as a test, a volume control, and he thought it would never work... But it worked, and it was pretty nifty, and there was an ounce of excitement. That was in the 5.4 days I think.

Then every corner-case and potential wrong-thing everyone could think of was thrown at me, and I spec'd and spec'd a monstrosity of an API to accommodate every concern everyone related to KWin had. It was death by bureaucracy. The real sin there? If there was an ounce of trust that designers might do the right thing, we could have had a very nice relatively streamlined implementation running today, and we would have had several iterations of Plasma to really make it shine. Now it's dead because of reasons like "something might look weird", "we 100% need the title every time", and my favorite "I prefer the titlebar" (as said by the people who made the titlebar)

I don't mean to dump on Plasma/KDE. I will also very strongly point out that because the developers have prioritized technology Plasma and KDE Gear has some of the most impossibly flexible applications in existence. There has been incredible work and I still use Plasma because it's genuinely the best desktop environment in my opinion. But there are some top-down ways of doing things which really do place technology over UX.

I look at projects like Maui and Deepin and that new Jing thing which use KDE stuff under the hood, and each and every one of them is jaw-droppingly stunning. From nowhere to some of the most beautiful pieces of software I've ever seen. Thanks to KDE. KDE does produce technological jewels, and in all love and respect I think there's some people in the core team who need to get out of the way and place their trust in developers further up the stack, otherwise one of these other projects will eat KDE's lunch.

[ssokolow]

I wonder if we could overlay a "server side region" that can override those CSD windows. Such region will cover the whole titlebar or at least the min/max/close buttons region of those header bar. If implemented, within such region, dragging the window will always work even for hanging / unresponsive window. A right click will produce a server side menu that will always provide all options provided by the windows manager.

That was what a GNOME guy reassured me with when I brought that problem up a decade ago on IRC... still not implemented as far as I can tell.

I prefer keeping Title Bars because similar to "prime numbers" I don't believe that you can continue to simplify beyond a certain limit and obfuscating software UX.

TL;DR; Simplification Good. Oversimplifying Bad.

Genius Simplifies. Ignorance Complicates.

"Everything should be made as simple as possible, but no simpler" -- Paraphrase of Albert Einstein

To be frank I never see the point of CSD vs SSD.

Even in the X11's SSD days, there is nothing stopping the application from requesting a borderless windows and do whatever it wants, making the application effectively CSD (like lots of games).

On Windows such kind of apps was already widely spread even before the proposal of Wayland (or even the word "App" itself).
The earliest one I can remember dated back to VB6 days.

Ultimately it's up to the app to comply with the decoration policy since the beginning. I really can't see the reason forcing SSD and then pretending app won't do the other way.

Same reason we moved things like sound card drivers from being bundled with DOS games to built into Windows. A centralized repository of user-adjustable good defaults so applications aren't caught between:

• Burn a lot of time reinventing wheels to ensure the user gets the same experience they would have gotten with a centralized, shared definition of the behaviour
• Deliver a shoddy experience to the user by implementing the bits you feel are important and ignoring the rest. (As they say when talking about attempts to oust Microsoft Word, "Yes, 80% of the people only use 20% of the features, but nobody uses the same 20%".)

That's part of why I despise "reinvent templating and CSS and a million other browser-default functions in client-side JavaScript" frameworks, aside from their fragility when exposed to network hiccups.

[curfew]

Graham must be referring to the workflow of clicking on a menu, not releasing the mouse button until the cursor is on a menu item, and then releasing the button to select that item. So yes, it technically conflicts with a headerbar widget being draggable to move the window around and, in fact, hamburger menus on GTK apps don't allow for that.
Question: is this important, one way or the other?

It is very convenient. I used to use that while I was on Xorg. Curiously enough I've been also told by Qt/KDE developers that this very behavior is the result of a Xorg bug that allows one to open a context menu by pressing the context menu button down, then "drag" the cursor through the menu, and finally trigger the hovered menu item by releasing the context menu button.

Maybe the actual bug is specific to context menus but then the behavior has been intentionally cloned to work with any popup menu too. On GTK the popup menus don't open until the mouse button is released, hence disabling this behavior completely, but enabling one to drag the CSD windows by grabbing on to a menu button too.

[curfew]

The arguments on that blog post are simply re-tarded.

1) They would either lose a lot of space used for dragging the window, or else lose the ability to click-and-drag-and-release to activate headerbar items in menus, comboboxes, pop-up menus, etc. You can’t have both with CSD headerbars.

Nobody is asserting that this behavior is mandatory or even preferred.

Sometimes it is even very annoying because it's too easy to click the menu, accidentally move the cursor a couple pixels, and then have the first menu item triggered because you happened to release the mouse button "in the wrong place". This is actually what I complained about years ago on Qt's IRC channel and the devs there told me that this behavior isn't even intentional -- it is an unfixable bug in Xorg!!!

2) There would be no place to display the name of the app, window, or open document–unless the app left a big empty space in the middle of the header for it. Even then it would be up to every app to implement this title itself, rather than it being an automatic thing provided by the window manager.

Why should the application advertise its branding to already active end-users anyway? That's complete utter nonsense and also waste of space. Having trash in the window title also makes it harder for users to parse the meaningful part of the title. AFAIK there isn't even a native way for appending app name into the title, hence it must be applied manually, meaning that each and every app might have an inconsistent way of forming the window title.

3) We would probably have to remove or severely restrict how customizable the toolbar can be given the above restrictions on space.

Rather they would have to define a new set of features and limitations. Already now the Qt/KDE toolbars are pretty limited and hard to configure at times.

4) Also given the above restrictions, the CSD headerbar would probably have to omit some of the window decoration buttons currently present on the SSD titlebar, since they would be taking up a lot of space that apps would need. Customization flexibility would also be reduced.

Even as a power user I wouldn't prefer having a dozen rarely needed buttons on the title bar. Especially given how tiny KDE window title buttons are, it's way too easy to accidentally press the wrong button. I would prefer leaner and safer way for triggering window actions.

5) Windows would all have to have hamburger menus with no provision for a traditional in-window menubar, since there is nowhere to put one in a CSD headerbar without it looking really weird.

Not presenting the case why traditional menu bars would be needed at all (aside some accessibility concerns maybe). And aside some tabbed applications, I don't think having the menu bar at the bottom of "chrome" (region of static controls above dynamic content) would look "weird" at all.

6) When a window is not responding, the close button would not work to force-quit it, since it would be drawn by the thing that is not responding (the window) rather than a thing that is still working (the window manager)… unless the window manager itself implemented a hack for this. So it would not work in other window managers.

There should be a well-defined Wayland protocol for detecting and handling unresponsive apps. It shouldn't be a proprietary feature in the first place.

Personally I would like to be informed of unresponsive apps already before I become aware of the fact that a random app has been consuming 100 % CPU for ten minutes and makes my laptop boiling hot. It would be trivial to detect a "frozen" app and display some sort of WM-provided overlay on top of it to make users aware of the situation. Title bar buttons are not needed for killing unresponsive apps! Straw man!