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

[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.

[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.

[skeevy420]

From Graham's post:

... Huh??
If you try to actually use a GTK app in GNOME for less than one minute and try that out, you'll find out that widgets on the headerbar can be clicked or dragged, and dragging them moves the window. Zero technical reasons why a headerbar widget wouldn't be able to act as draggable area. It's also intuitive and easily discoverable.

Unless the point here (although badly written) is that you can't have a widget that functions by dragging its contents and also have it draggable to move the window, which would be... peculiar?

(And of course there's the matter of CSD != headerbars as already pointed out by other users.)

Edit: nevermind, I think I got it. 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?

In all fairness he says "GNOME-style client-side decoration headerbars" early on in the blog post and from there on refers to everything as CSD or headerbar.

[JackLilhammers]

It's also intuitive and easily discoverable.

That's debatable at the very least.
Why should I think that a button or a switch or a text edit field, which have their very distinct usage, would act also as a draggable handle?
It's not intuitive and it never was.
By the way, I think that on MacOS headerbar widgets do not drag the window, ergo it's not even familiar for someone coming from outside of Linux, specifically from outside of Gnome.

Unless the point here (although badly written) is that you can't have a widget that functions by dragging its contents and also have it draggable to move the window, which would be... peculiar?

Of course that's exactly the point. And it's not because one would want a slider that can also be used to drag the window, but because sliders "break the rule".
By the way, in my opinion MacOS implementation is way better, because first there is no subtle functionality and second the fact adding widgets to the headerbar quickly reduces the draggable area keeps the amount of widgets to a minimum, which again in my opinion fits with the purposes of a headerbar

[Charlie68]

The issue is rather that KDE, mainly Kwin always bugged out with CSD clients.

Them finding a solution on accident is nothing surprising, it seems like most things that work on KDE work by accident.

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.

... ... it is evident that you are a fan of Gnome and this post testifies to it.

[skeevy420]

The issue is rather that KDE, mainly Kwin always bugged out with CSD clients.

Them finding a solution on accident is nothing surprising, it seems like most things that work on KDE work by accident.

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.

Yeah. A lot of us treat CSD to be synonymous with "the GNOME HIG's implementation of CSD" when that's technically not the case. I know I have before.

But in regards to how KHamburgerMenu works and header bars in general, my biggest issue with the GNOME HIG is that it moved all the window management controls to a submenu aside from close and double clicking the header bar. It would be cool if GNOME and KDE could agree on a CSD design that's minimalist by default but allows a KHamburgerMenu button to expand out to more window management controls or even allowing us to do a double header bar that's only used for expanding window management controls if we're cluttering up the header bar. The extra bar would be halfsize or smaller because all it is for is window management...basically bringing back what a titlebar does now in a way that should hopefully work for both minimalist and non-minimalist users. All I can do is suggest that.

You know, that could work both ways with an extra bar going down if a user wants to add more application controls from the app's menu.

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.

[chocolate]

From Graham's 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.

... Huh??
If you try to actually use a GTK app in GNOME for less than one minute and try that out, you'll find out that widgets on the headerbar can be clicked or dragged, and dragging them moves the window. Zero technical reasons why a headerbar widget wouldn't be able to act as draggable area. It's also intuitive and easily discoverable.

Unless the point here (although badly written) is that you can't have a widget that functions by dragging its contents and also have it draggable to move the window, which would be... peculiar?

(And of course there's the matter of CSD != headerbars as already pointed out by other users.)

Edit: nevermind, I think I got it. 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?

[ssokolow]

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.

I'll agree that I think header bars are a bad idea, to be ripped out and replaced if at all feasible (If I had the time, I'd try writing a replacement for Flatseal that doesn't look like a badly GNOME-skinned tablet app), but my arguments against CSD in general are more in the vein of the Arcan complaints.

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 fight hard to ensure my applications are as consistent as possible.

I actually use all that stuff KWin stuffs into the context menu for window decorations, and I like being able to customize the layout of my titlebar buttons and have everything obey.

Need I go on?

[Britoid]

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.

[Alexmitter]

The issue is rather that KDE, mainly Kwin always bugged out with CSD clients.

Them finding a solution on accident is nothing surprising, it seems like most things that work on KDE work by accident.

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.