This is a follow-up post to my client-side-decorations (CSD) on Wayland post. Personally I was positively surprised by the feedback in comments and on various media sites. Hardly any “you are an idiot” – for a controversial subject this is very positive.
There was one comment which motivated me to write another post on the topic:
I see strong arguments/feelings for both CSD and server side – can there by a hybrid approach?
This is exactly the point. Neither client side (CSD) nor server side decorations (SSD) are the holy grail. Both have advantages, both have disadvantages. Nobody is right here, nobody is wrong. If someone says he prefers CSD, he is right, if I say I prefer SSD, I am right. That’s quite important to get. In the end one has to evaluate the advantages and disadvantages and then decide which is the less evil.
For me this is server side decorations because of the disadvantages I pointed out for our workspaces. Others might decide differently and that’s just fine. I do not want to enforce SSD on anyone who prefers client side decorations.
In fact I would be fine with CSD if there would be an approach to make them work right. There have been many comments that it really doesn’t matter as it belongs in the toolkit and they will look the same. Yes of course, I agree that decorations belong into the toolkit and that they should adapt to the needs of the workspace they are running in. But I don’t believe the toolkit (except Qt) can do that. As long as there are so huge integration issues like getting an unfitting file dialog in the KDE workspaces, I just don’t trust that toolkits can do it. In that aspect there have been quite some comments, that the integration is already really bad, so it doesn’t matter if that part breaks as well. Let’s just say that I disagree here 🙂 I want to have more integration not less.
So in the end it has to be a hybrid approach. There are valid usecases for client side decorations even on a system enforcing server-side decorations (best example: Yakuake), but if the system does not want decorations (e.g. Plasma Active) the client’s should not draw an own decoration. And of course there is the Chromium use-case where the user should be allowed to decide.
All it needs is a small protocol allowing the server to negotiate with the clients whether CSD should be used or not (that would be useful on X11, too). This actually does not mean an overhead, because also for CSD there should be some negotiation between server and client to figure out things like button position, which buttons, colors, style and so on – which goes in the direction of CSD done right. Just saying: “it’s the Client’s responsibility” is causing the issues I’m afraid of.
Well then, go ahead and _design_ this protocol. I can hardly think of someone more suited…
At the very least, it would be nice if all toolkits respected an environment variable WAYLAND_NO_CSD, so that non-qt apps on SSD kde wouldn’t carry double decorations.
“In that aspect there have been quite some comments, that the integration is already really bad, so it doesn’t matter if that part breaks as well.”
I’ve often heard this argument too, but I don’t think it has much merit.
From a usability perspective, consistency in window handling is a very different thing and *much* more important than consistency between the contents of different windows, so the comparison falls flat.
Windows represent contexts. Humans usually have no problem learning and applying context-sensitive information, so if two applications behave differently *within* their respective contexts, and have to be “learned” separately, that’s not a big problem.
However, moving/minimizing/switching windows and most of the other tasks that the window decoration allows users to do, are not part of the application’s context, they belong to the meta-context of interacting with and managing multiple context.
If you see 10 windows on your screen and want to find a specific one and bring it to the front, you don’t want to deal with each of the windows you’re moving out of the way or minimizing to behave differently and require different interaction to complete this straightforward workspace task.
If you’re in the process of moving windows around, and say, unexpectedly bump into one that does not respond to dragging, forcing you to recognize “ah, yes, this window belongs to the Steam client and unlike my other apps this particular program has chosen to make the window decoration unresponsive for windows that have active modal dialogs”, that’s just horrible usability.
Context switches being expensive is not just true for OpenGl code, but also for human brains… 🙂
Unless they provide a clearly explained and differentiated special use case that requires this (like Yakuake), windows should *not* have any say in how they are handled and managed in relation to other windows. Workspace organization tasks belonging to the workspace context, not just technically but also mentally.
i wonder whether due to waylands input redirection such “hybrid” approach could be actually a hybrid in that the server tells the client:
window + n px high titlebar (and m px border) so that the client will create an overscanning surface – the client could even pre-fill it with a matching background.
then the server kicks in and decorates the surface on the titlearea a bit before mapping it onto the screen, ie. maybe paint an outline but most importantly the buttons (client could hint the color/s here) and controls away the input in that area (ie. hadles thatitself, not passing it to the client)
Thinking about it:
with the input window this would even be possible on X11 for supporting client toolkits (and compositing) – all others (or w/o compositing since we don’t get into the clients backbuffer) get a “regular” decoration.
Requires major adaptions in the decoration API, but that’s on topic anyway.
>so that the client will create an overscanning surface [cut] then the server kicks in and decorates the surface on the titlearea a bit before mapping it onto the screen
I think that with DRI3000 ( http://mirror.linux.org.au/linux.conf.au/2013/mp4/Future_directions_for_the_X_Window_System.mp4 http://lwn.net/Articles/536484/ ) Keith Packard suggested this for X.
With Wayland, I’m not sure that this is possible a regular contributor on Wayland’s devlist told me that a compositor cannot write to the client’s buffer for security reason..
Perhaps the hybrid approach could be, the server can be configured in some way to ask Applications for their CSD in some manner(instructions for drawing it, or maybe some sort of buffer containing the CSD already drawn), which the server would then be responsible for rendering, or the server can just draw its own CSD, Even on a window-by-window/program-by-program basis
It would be cool if a chromium-like functionality was implemented in the toolkits. So that e.g. all KDE application have the option to use either csd or ssd.
example use case:
http://s1.directupload.net/images/130209/iy6m7nqm.jpg
If you think like me that native decorations would be better then you could just turn on csd for dolphin and if you rather like to have a consistent behavior then you would turn on ssd and it would look like in the screenshot.