Dear Mark Shuttleworth,

so you “have absolutely no doubt that Kwin will work just fine on top of Mir”. This is great and I totally appreciate that you think Mir is a great system. But I’m wondering why you don’t use KWin then, after all it will work fine on top of Mir and is Qt based?

But I have doubt that KWin will work just fine on top of Mir and I have already stated so. You might have wanted to check the facts before stating such claims (somehow I get a feeling for a pattern here).

What makes me think that you cannot make such bold claims:

• You don’t even know how to write KWin
• Currently the number of commits to KWin by an Canonical employee is 0 (git log — kwin | grep @canonical)
• No Canonical employee has so far contacted the KWin team on how we could integrate Mir and whether we are interested at all
• I have to question the abilities of Canonical to judge what other software can do and cannot after Canonical argued with non existing issues in Wayland for Mir
• We are still waiting for the Wayland adjustments for KDE done by Canonical. May I remind you:
  

  We’ll help GNOME and KDE with the transition, there’s no reason for them not to be there on day one either.

I have to ask you to keep KWin out of the pro-Mir campaign. I didn’t ask for Mir, I don’t want Mir and reading blog posts like the one which triggered this reply does lower my motivation to ever have anything to do with Mir. Mir is an answer to a question nobody asked. It’s a solution to problem which does not exist.

Your community manager recently posted on Google+ he had a frustrating day. Guess what my week has been and guess who I can blame. Guess what I great day I will have after reading your blog post this morning.

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.

This weekend I was at FOSDEM and attended a talk about Wayland for application developers. One thing that came around multiple times was that “applications have to provide the decorations”. Every time I had to cringe, because it’s just not true and I find it sad that people who give presentations about Wayland repeat that.

Nothing in the Wayland protocol requires Client Side Decorations or forbids Server Side Decorations. And that’s not surprising as it just should not matter to a protocol. The same is true for the X11 protocol, there is nothing said about window decorations. Just on X11 people realized that server side decorations are the better choice, but still there are applications doing client side (maybe people think that the possibility of re-parenting says anything about window decorations, it doesn’t you don’t need re-parenting to provide server side decorations). What is true is that the reference implementation of a Wayland compositor, Weston, requires Client Side Decorations, but it’s just one implementation and doesn’t say anything about other implementations. And here it’s important to remember that Weston is not Wayland.

There are good arguments pro and contra client side decorations. The most commonly listed ones pro client side are:

1. Only one texture needs to be rendered
2. No aliasing when rotating/wobbling windows
3. Application developers are free to experiment

The first two are true. I have to agree there. I know KWin’s OpenGL decoration rendering code and the problems with it. I do not like it and I do see the disadvantages. Also I do know that wobbling windows is not looking nice.

The third argument is more complex. Here I do not agree, because I have not seen any valid use cases for these “experiments”. All we have so far is the Chromium use case and since then nobody else came up with any use case. So somehow that shows that we are not restricting the application developers as some pro-CSD people would claim. In fact allowing CSD limits the possibilities of the workspace.

Plasma provides three workspaces: desktop, netbook and tablet. From KWin perspective the main difference is how window decorations are handled. On Desktop we have full decorations, on netbook we disable decorations for maximized windows (control moved to the Shell’s panel) and on active we don’t have any decorations at all. With client side decorations such possibilities are gone. We are no longer able to take the desktop further by just changing this aspect for all applications. Many KDE applications are useable on Plasma Active (tablet) without any adjustments. If they would use CSD they were not usable.

My main fear with CSD is that it ends up in a mess as we can see on Microsoft Windows. There CSD are common but applications don’t use it to do useful stuff, but to enforce their corporate design. This is bad for usability. Each application looking different? Stupid idea. Not even Microsoft is having a consistent decoration for their various products. Some have titles on the left, some centered. A complete mess. And my fear is that Linux would head there, too.

Is this fear valid? Well during said presentation Weston was running with two windows. They had different decorations. One was the terminal with minimize, maximize and close button on the right. One was a pdf viewer with a standard GNOME Shell decoration: minimize button missing. And during FOSDEM I had also a look on the decorations for Qt Wayland: again different decorations.

Now let’s take that further: an application for Unity will have the buttons on the left, a decoration for KDE will have two on the left and three on the right. Everything will look different, just on one system. Total mess and nothing I want to use (yes that would be a reason to switch to Mac if that would happen).

I had a talk with Andy from Qt Wayland fame about the CSD implementation and he explained me that inside Qt the CSD code gives some overhead and that they have a flag to turn them off. Which is great. And we in KWin already have server side decorations and will need to keep them around for legacy X applications. What’s the point then to use CSD in Qt if we already have the decorations and can give the application a better performance? Well none and that’s why I plan to use server side decoration in KWin on Wayland.

So if you read again somewhere that Wayland requires Client Side Decorations:

• Nothing in Wayland requires them
• QtWayland allows Clients to turn them off
• KWin as a Wayland compositor will use server side decorations

I do not want to go into the details of the contra arguments of Client Side Decorations as I have done that in the past. It’s a difficult topic as both pro and contra arguments are true. I personally see the contra arguments – especially the inconsistency – as much worse than the possible benefit of any possible pro argument. And please don’t come to my comments section and tell me that one can standardize on how the decorations should look like. If that were possible and feasible and would be used by application developers, we would not have already at least three different decoration implementations. It will end in the fancy I’m important mess from other systems.