Views on Client Side Decorations (CSD)

Ferdinand · 2021-03-22 07:42:58

Delegating responsibility for window decorations to the client rather than the Window Manager, means that individual applications can decide how their window decorations will look and function.

Wikipedia wrote:

By using client-side decoration rather than traditional server-side decoration, applications are able to draw their own title bar, which allows for a wide range of possibilities to customize window decorations and add additional functionality (graphical control elements) into what otherwise would be a typical window manager bar with much empty space in the maximized windows.

It seems Qt does not implement CSD, while GTK does through GtkHeaderBar widget (the Gnome-thing on top of windows, instead of a title bar) and other toolkits also implements CSD.
As application developers choose freely what toolkits and widgets to use for their applications, all kinds of variations exists.

As an example, Firefox uses client-side decorations when the title bar is disabled.

So, we can have both WM-controlled window decorations and application-controlled window decorations, all within a range of different toolkits.

Freedom-wise it sounds pretty good. But for having a uniform desktop where all applications obey your theme decision, it can be a bit of a mess.

Consider Xfce going for CSD, using the GtkHeaderBar. If you like it or not is a subjective thing, but it does mean your windows will no longer follow your theme, and so you will lose some uniformity.

The problem of obtaining a uniform look has always existed of course - as in using a mix of Qt and GTK applications for example - but with CSD picking up in a lot of toolkits, and seemingly becoming rather popular, we're moving towards a situation where Window Managers are sidelined, themes looses their usefulness, and users looses power over the desktop appearance.

I have decided I don't like this at all, and now use libxfce4ui-nocsd.
I fear this is only a temporary solution however, and I am concerned for my desktops future good looks, and I am starting to fear I will have to abandon my dear Xfce and seek refuge in KDE

So what are your views on all this?
Am I overreacting, or plain wrong?
Or, is this the end of the world as we know it?

Last edited by Ferdinand (2021-03-22 07:46:16)

merlock · 2021-03-22 13:40:11

I use sway (formerly i3), and have title bars turned off, so for the most part I'm unaffected.

BUT...

When I was using GNUCash this past weekend, I did notice that long-time layouts of it's file-chooser and print dialog changed (and not for the better, IMO).

What used to be (to me) nice and cohesive (OK/Cancel buttons nice and tight on the lower right corner, with a nice unobtrusive dialog window) has now morphed into a monstrosity that by default now has the OK button on top-right, Cancel button on top left, along with that moronic hamburger menu button. By default, on my machine (I'll work on the sizing) the dialog now takes almost 3/4 of the screen.

So, in my minimal exposure to CSD, I pretty well don't like it. For those that have to deal with it daily....sucks to be them.

SzzS · 2021-03-22 19:49:25

I join the previous speakers.
I using Manjaro and Arch Linux on my desktop PC's with XFCE, and Arch on my old laptop, with QTile Windows Manager. Simply as that, I hate CSD.

Trilby · 2021-03-22 19:59:51

That wikipedia excerpt is mostly gibberish. There are no "server side decorations". Client-side decorations are the mechanism by which each individual client program draws their own decorations the way the upstream author chose rather than having one client program, the window manager, consistently apply the user's preferences to all windows.

Ferdinand wrote:

As application developers choose ... all kinds of variations exists.

Exactly, the application developers choose, not the end users.

Ferdinand wrote:

Freedom-wise it sounds pretty good. But for having a uniform desktop where all applications obey your theme decision, it can be a bit of a mess.

How is that good "freedom-wise"? It takes the choice and control out of the hands of the user. It's good for the developer's freedom ... kinda', but really why would they care. As you note, you no longer have the freedom to have applications obey your chosen theme decisions.

Ferdinand wrote:

Window Managers are sidelined, themes looses their usefulness, and users looses power over the desktop appearance.

Yup. Users lose power - where's that freedom you mentioned?

I agree with your critiques of CSD. But I'm really curious how you, as someone who doesn't prefer it, is still somehow convinced of CSD providing some dellusion of freedom.

Last edited by Trilby (2021-03-22 20:03:30)

Morn · 2021-03-22 20:11:12

I blame 16x9 displays. The Chrome devs decided that a title bar wasted too much vertical space and then the Firefox and Gnome devs followed suit. So now we have almost nowhere to grab these CSD windows and the title bar is cluttered with buttons, search boxes, etc. What an awful look.

The funniest thing is that the Xerox Star already had cluttery buttons in the title bar way back in the early 1980s, so the Gnome 3 look is not even remotely new: https://www.mac-history.de/wp-content/u … ar_gui.jpg

Ferdinand · 2021-03-24 10:40:12

@Trilby, I'm afraid you misunderstood me - or I expressed myself clumsily.
What I meant with the freedom-wise comment was not to, in any way, give praise to CSD, rather to take the edge of my own comments by not being too one-sided

To my defence; on a conceptual level many options does allow for choice, and to lean a little more on what somebody wrote on Wikipedia - "Freedom, generally, is having the ability to act or change without constraint".

However, in my view, the number of applications available in Linux is not big enough that you can make a choice and find all the applications you need among those that adhere to that choice - and if I am forced to accept somebody else's idea of what looks nice, then I consider that my freedom is directly reduced.

To the extent that I can protect myself I wiil; currently my defence is libxfce4ui-nocsd, but if that falls, I might have to flee - and my original post was meant to also investigate that aspect; where can one flee? I'm looking to KDE, which I'm sure is a decent DE - but choosing to flee is a poor way to be free

Last edited by Ferdinand (2021-03-24 10:42:12)

Trilby · 2021-03-24 14:58:08

Ferdinand wrote:

To my defence; on a conceptual level many options does allow for choice, and to lean a little more on what somebody wrote on Wikipedia - "Freedom, generally, is having the ability to act or change without constraint".

But that's my point. CSD takes that away. CSD is a constraint. I'm all for concessions, and there are points we could find in favor of CSD (they may be necessary if/when wayland becomes the dominant display server), but (user) freedom just can't be contorted into being a concession for CSD as it's really it's biggest weakness.

seth · 2021-03-24 15:27:10

CSD is a dumbfuck idea, born out of (somewhat valid) aesthetic concerns because the async nature of X11 would (before the introduction of the SYNC protocol) result in tearing between titlebars and the client during resizes.
Also Apple be cool…

Downsides:
1. if when the clients event loop stalls, you can't use the titlebar to control or even move the window (inb4 "alt+mouse": see bottom)
2. Every developer being a very special creative snowflake and placing buttons of individual random look into individual random location makes muscle memory useless
3. Active client indication is apparently for losers, pros probably only use maximized windows all the time…
4. Which mouse button does what action on which section of the border to resize the window?
5. Btw, what if the user configures the WM to eg. *only* raise windows when explicitly clicking the titlebar?
6. Window Tabbing, Shading and GUI access to further features (layer control, stickyness, …) or special stuff like hiding titlebars for maximized windows etcetc.
7. Incoherent w/ client specific overrides or modality handling in the WM - you get buttons that don't do anything or lack thereof
8. There is gonna be the one genius developer who doesn't trigger the WM to perform move/resize, but implements it in the client… (I happen to know a genius how tried that almost 20 years ago…)
9. It's a visual fucking mess
a. Real men™ don't use titlebars to begin with

1 & a kinda circle the contradiction: The users most relying on the titlebar as GUI component of the WM are the ones that gets the most fucked by the biggest design flaw of CSD.
If they try to close a hanging client, the WM will kindly inform the client to fuck off and if the client doesn't listen check whether it's listening at all and if not it can just kill it for the user (either through xkill or _NET_WM_PID
With CSD they can't even move it out of the way

A much better approach to get the hamburger icon into the titlebar would have been to extend the protocol (client says: "want hamburger", WM adds hamburger and informs the client when and where it's triggered, so the client can popup its menu there) or to add some text buttons (client says: "add me an ok and a cancel button in the locale-aware position", WM says "ok" and informs the client when they're triggered) so one could have made better use of the screen real estate without going for the naive approach.
"Naive" because when I first got aware of the fact that the titlebar is not the client, I thought "now, that's stupid" but with much more experience and more than a decade in and around (pretty high profile) WM development I've to assess: "geezz…, was I stupid back then".

seth · 2021-03-24 15:33:59

Trilby wrote:

they may be necessary if/when wayland becomes the dominant display server

Nope.
There was a lot of talk about that back in the day and then lead-dev of kwin blogged about it:
http://blog.martin-graesslin.com/blog/2 … d-wayland/
https://blog.martin-graesslin.com/blog/ … corations/

Not sure whether it's still the KDE position, but wayland doesn't mandate nor require CSD.

Trilby · 2021-03-24 16:19:02

seth wrote:

Trilby wrote:
they may be necessary if/when wayland becomes the dominant display server
Nope.

That's good to hear. I wasn't sure - but I know it was a potential (or perhaps naively FUDed) issue. I guess that said, I'd have to look harder for any valid concession in favor of CSD. I don't doubt it has some merits ... but I certainly can't list any.

Last edited by Trilby (2021-03-24 16:21:38)

Head_on_a_Stick · 2021-03-24 16:42:46

I like CSD. I find them both efficient in respect of space usage in the title bar and also aesthetically pleasing.

seth · 2021-03-24 16:54:01

Which is fair enough.

On my less manly system I spent quite a moment to integrate the header of ncmpcpp w/ the titlebar (what required me to substitute the terminal border ;-)
My first interaction w/ KWin ever was actually to bend the kdecoration API to a similar effect.

The problem is, as suggested before, not so much the desired outcome, but the technical approach.

Trilby · 2021-03-24 21:14:44

Head_on_a_Stick wrote:

I find them both efficient in respect of space usage in the title bar and also aesthetically pleasing.

So WMs should use space more efficiently (some do, e.g., fluxbox's "tabs") and could be more aesthetically pleasing (some likely are as there are all variets, even within a WM, XFWM has a ridiculous number of widly varied themes). But neither of these criteria require that the decoration be done on the client side. The fact that they may be well done doesn't mean they were done in the right place.

NuSkool · 2021-03-25 00:33:37

I don't care for it based on what I know.

TIL: libxfce4ui-nocsd https://aur.archlinux.org/packages/libxfce4ui-nocsd/

So can client-side decorations disable or replace the window manager functionality? ie: remove/replace close, maximize, minimize buttons, how about menu bars?

I've held back on the current XFCE and related updates till the dust settles, specifically relating to client-side decoration and any other potential disruptions GTK may introduce in my "conventional paradigm" layout DE choice. ie: G3 shell is not my preference.

I am somewhat concerned with what seems IBM/RH/G3 mostly/completely controlling the direction of GTK. Is GTK eventually to become a "for G4/Wayland only" project in the future? Anyone else find it ironic the current position of the Gimp project (origins of the "G" in GTK) is regarding GTK implementation?

I've read of patches being ignored that fall outside outside the "useful to G3" category. There are a lot of projects out there relying on GTK. Seems this gives G3 a whole lot of influence in the adoption of "unconventional G3" type behavior.

Does this mean smaller projects like XFCE can be coerced into offering a "G3-G4 lite" like DE that follows their idea of G4 cell phone like look and workflow on my desktop. Hopefully I'm way off on this.

The G2 project was in my opinion, intentionally and unnecessarily killed off and extinguished. The project I feel was responsible for this has lost my trust in their intentions and future direction.

I've been playing around with LXQT just in case a clean exit strategy is required for when GTK4 is implemented in XFCE, to avoid another unplanned exit as was the case I faced as a Gnome 2 user.

    Updates available, not downloaded:
--  exo                   0.12.11-5    ->  4.16.1-1     [ignored]
--  garcon                0.6.4-2      ->  4.16.1-1     [ignored]
--  gtk3                  1:3.24.24-2  ->  1:3.24.27-4  [ignored]
--  libxfce4ui            4.14.1-3     ->  4.16.0-1     [ignored]
--  libxfce4util          4.14.0-2     ->  4.16.0-1     [ignored]
--  parole                1.0.5-1      ->  4.16.0-1     [ignored]
--  thunar                1.8.16-1     ->  4.16.6-1     [ignored]
--  thunar-volman         0.9.5-3      ->  4.16.0-1     [ignored]
--  tumbler               0.2.9-3      ->  4.16.0-2     [ignored]
--  xfce4-battery-plugin  1.1.3-2      ->  1.1.4-1      [ignored]
--  xfce4-panel           4.14.4-1     ->  4.16.2-1     [ignored]
--  xfce4-power-manager   1.6.6-1      ->  4.16.0-2     [ignored]
--  xfce4-session         4.14.2-2     ->  4.16.0-1     [ignored]
--  xfce4-settings        4.14.3-1     ->  4.16.0-1     [ignored]
--  xfce4-terminal        0.8.9.2-2    ->  0.8.10-1     [ignored]
--  xfconf                4.14.4-1     ->  4.16.0-1     [ignored]
--  xfdesktop             4.14.3-1     ->  4.16.0-1     [ignored]
--  xfwm4                 4.14.6-1     ->  4.16.1-1     [ignored]

Ferdinand wrote:

and users looses power over the desktop appearance

TLDR: I'm more concerned with loss of functionality, along with appearance.

EDIT: For more details on GTK's CSD implementation: https://forum.xfce.org/viewtopic.php?id=13689

Disclaimer: I'm old and stupid. Disregard this if I'm out in left field.

Last edited by NuSkool (2021-03-26 16:57:12)

Ferdinand · 2021-03-25 06:47:51

NuSkool wrote:

So can client-side decorations disable or replace the window manager functionality? ie: remove/replace close, maximize, minimize buttons, how about menu bars?

Yes - because the CSD widgets doesn't use any decoration information from the Window Manager.

In Xfce 4.16 they started changing stuff a lot.
Here's the announcement: https://xfce.org/about/news/?post=1608595200

The two changes with the biggest visual impact are:

Icons: They're changing the naming structure and have provided new icons.
CSD: They are using CSD in all the setting dialogues.

Luckily both can be countered:

Substitute Xfce icons with icons from your favourite theme.
First find all the new icons by doing a find /usr/share/icons/hicolor -name "org.xfce.*"
Then create a copy of your theme directories under ~/.local/icons and link new names to old files
I made a script to fix the Faenza theme I use, but it can be easily modified to any theme: http://ix.io/2U1o
Install libxfce4ui-nocsd - it will take care of the Xfce settings dialogues, but also do what they say on the GitHub site (https://github.com/Xfce-Classic/libxfce4ui-nocsd):
```
$ xfconf-query -c xsettings -p /Gtk/DialogsUseHeader -s false
```
in order to remove CSD from all applications that use GTK3 dialogues (there are more CSD applications there still, so it won't fix all, but that can't be blamed on Xfce)

This way I have Xfce 4.16 without CSD and with my nice Faenza icons - it still looks and functions like it did in Xfce 4.14, so you can update if you like

Edit: Added pictures

Xfce 4.16 settings with CSD (this is just an image from the net, with the new Xfce icons):

Xfce 4.16 settings without CSD (from my computer with Faenza icons):
And in case compactness or screen estate is an issue, they could've just dropped the title area (shown in edited image to the right)

Last edited by Ferdinand (2021-03-25 07:42:48)

Arch Linux

#1 2021-03-22 07:42:58

Views on Client Side Decorations (CSD)

#2 2021-03-22 13:40:11

Re: Views on Client Side Decorations (CSD)

#3 2021-03-22 19:49:25

Re: Views on Client Side Decorations (CSD)

#4 2021-03-22 19:59:51

Re: Views on Client Side Decorations (CSD)

#5 2021-03-22 20:11:12

Re: Views on Client Side Decorations (CSD)

#6 2021-03-24 10:40:12

Re: Views on Client Side Decorations (CSD)

#7 2021-03-24 14:58:08

Re: Views on Client Side Decorations (CSD)

#8 2021-03-24 15:27:10

Re: Views on Client Side Decorations (CSD)

#9 2021-03-24 15:33:59

Re: Views on Client Side Decorations (CSD)

#10 2021-03-24 16:19:02

Re: Views on Client Side Decorations (CSD)

#11 2021-03-24 16:42:46

Re: Views on Client Side Decorations (CSD)

#12 2021-03-24 16:54:01

Re: Views on Client Side Decorations (CSD)

#13 2021-03-24 21:14:44

Re: Views on Client Side Decorations (CSD)

#14 2021-03-25 00:33:37

Re: Views on Client Side Decorations (CSD)

#15 2021-03-25 06:47:51

Re: Views on Client Side Decorations (CSD)

Board footer