A study of what-if scenarios which posit what KDE would look like if it took a different approach to certain aspects of design. Note that these posts are in no way “the direction KDE is going” and are simply a study done to reference designs and ideas we may never have investigated.

This is also an older what-if, and since it has been written, work on different approaches to design highly dynamic decorations has advanced. This post is here more/less for posterity. More info will come later on other methods.


“Client-Side Decorations” (or “CSDs” for short) are a method of decorating windows where the application is responsible for the window frame. Commonly, Linux and Linux desktop environments have favoured “Server Side” decorations (SSDs for short), where it was up to the window manager to draw the window frames. In this “What if” scenario we’ll explore two hypothetical applications; a media player and a PDF viewer, programs which might benefit from CSD technology. Before the CSD-enabled mockup, here’s what the media player application might look li ke using KDEs’ current SSD method:

And here’s what it might look like using CSD:


In the CSD design, the various window buttons are moved down into the control bar of the media player. This saves vertical space, meaning an un-maximised video will always be slightly larger. In addition, the buttons can follow a separate theme from the main window; in this case a less distracting button is used. Additionally, the application could partially fade buttons in the bottom bar, or, if the bar was laid over the video the entire bar could be faded out (when the mouse leaves) for maximum display – though this is not in the mockup.


In this PDF reader, the CSD is on the left, and uses the thumbnail column as the decoration. As PDFs generally tend to be a series of portrait sheets, vertical space is at a premium.

Technical Challenges

The main technical challenges faced by KDE developers is ensuring application consistency will continue to work under various form-factors. When Kwin (the KDE window manager) controls window borders, it can quickly and gracefully adapt to multiple form-factors. For example, in Plasma active space is at such a premium KDE can hide window decorations and embed them into the workspace itself.

The other technical challenge is protocol and cross-enviornment consistency. It’s known that CSD-enabled applications can look extremly awkward when window borders are wrapped around an application not designed to use them. In addition, protocols for drawing CSDs on Linux are a mish-mash at best, and CSD code tends to be far less portable to other desktop environments. Compounding that, KDE has additional features (such as window tabbing) which are inherently incompatible with the feature.

If KDE were to use CSDs, it would likely be preferable for all applications to support CSDs as a secondary ‘upgrade’ and default to using SSDs until the window manager explicitly enables the CSD; meaning KDE apps with CSDs would need alternate layout code. KDE might also need to reserve the ability to revoke CSDs from an application or flag them to keep CSDs disabled; for example, it might only allow Wayland-composited environments to use CSDs, as Wayland has protocols for CSD-specific problems (such as application hangups). It might revoke the CSD layout if a user disabled it, or if an application is moved into a window-tab.

Application crashes are another significant issue; If applications are made responsible for their own close buttons you enter a situation where the close button on a crashing program will fail to function. There are several technical aspects to this which can defer the impact, but in a worst-case scenario the GUI of an application will become an non-responsive picture. Wayland has solutions to detect this, while Xorg is a hot mess; if Wayland/KDE used CSDs, a window manager overlay might need to be created in the event of a crash to retake the minimal window-level control of applications.



  • Applications would waste less space on screen; for small laptops this is a significant advantage.
  • The decoration can be placed on any side. Applications like a movie player could hide decorations completely.
  • Applications with a full-screen mode may just use the same chrome in full-screen, maintaining placement of close/minimise/maximise buttons.
  • A strong CSD protocol/library could ensure reliability[/list]


  • Outside of the extra code overhead, applications could more easily break in the future as technology changes.
  • Depending on the implementation, applications could be larger.
  • Kwin would need more code to recover, mark, or kill crashed CSD applications.
  • Consistency is lost; Windows might place buttons on the top, bottom, left, or right. Users would need to adjust to applications individually.
  • Poorly chosen widgets can interfere with window dragging, space meant for dragging windows might be lost.
  • Depending on implementation, polling mechanisms might falsely label applications as non-responsive.

Other Points

  • Applications can crash many ways, causing whole-system breaks. SSDs can’t police the whole system; Bad applications shouldn’t be the example.
  • Using an “SSD until otherwise permitted” model can still allow users who dislike CSDs to enforce SSDs.
  • KDE applications are beginning to ship with multiple layouts for convergence purposes; CSD layouts might piggyback on this.



On a personal level, I love applications which properly use CSDs. They’re more screen-efficent and applications can look much more professional. I also believe that CSDs will be inevitable, and that a strong KDE CSD library which enforces smart use of CSDs would be better now than applications inventing their own solutions later; especially when other environments are starting to make good use of it.  After looking at Gnomes solution, I do think CSDs as-an-upgrade would be ideal, as applications can behave “normally” until they get the go-ahead to be shiny. This will help KDE apps fit into environments like Windows, OSX, or Gnome without issues. Also, users might want to forcefully disable CSDs desktop-wide for consistency purposes, and having CSDs as-an-upgrade would assist in this.

I also think that CSDs should also be required to adhere to Kwin specifications will first and foremost; while it’s nice applications might ‘brand’ themselves using colours or unique styling, I believe allowing Kwin to dictate the style would be a usability win. In addition, KDE 5 is incredibly friendly to dark themes (or is increasingly getting better at it), and allowing CSDs to colour themselves would take away from user options. On the other hand, since windows would not necessarily display titles, colouring becomes an important identifier.

I also like the idea that a full-screen application could just continue recycling the same piece of chrome; often applications use entirely different UIs in full-screen mode, which reduces usability – especially when hot-keys are required to exit fullscreen.

Technology-wise, I’ve read impressive articles on Wayland in regards to how they’ve thought through many CSD specific problems – such as application crashes rendering windows unmovable. No matter how its sliced though, CSDs should be approached carefully and thoughtfully if they were to be implemented as a part of KDE in the future.

In terms of the “simple by default, powerful when needed” mantra, CSD decorations follow the pros and cons listed above; mainly by making more efficient use of screen-space and giving applications a more simple, less intimidating demeanour. On the other hand, it decreases the intuitivity of applications by potentially moving window controls, or causing issues in event of a hangup. I think CSD driven designs tend to be more simple and reserved (at least as Gnome has done it). Disabling the CSD desktop-wide for features like window tabbing is where “powerful when needed” kicks in; especially since its an uncommon and difficult to discover feature.

One Last Note;

This is actually a fairly old what-if, and since it has been published work on different approaches to design has advanced. This post is here more/less for posterity.

Chime in!

What are your thoughts on CSD; what did I miss, any addendums? Let us know!

24 thoughts on “What if… KDE Started using Client-Side Decorations?

  1. For me, the most important point is consistance. Not only widgets should be all the same (Thanks, QtCurve!, damn you google chrome), but window decorations are especially important. I always want to have the close button where i expect it, i do not want to search it first in each application. And even when i know where it is, i like it more if it is there, where i configured it to be. For example i configured the buttons to be on the left side (Ubuntu / OSX style), because i tried it when i heard the reason, that the cursor is often in the upper left corner of the screen / window anyway and the menus are there as well. I noticed, it true and it speeds up reaching the Buttons. Other features like “drag to maximize” are useful as well. When i open evince with it’s CSD, it’s instantly a disadvantage.
    Then there are other factors. You put the close button in a different color to avoid it to be too distracting. Okay. But what, if i used a bigger font in my SSD? The close button in your program might not reflect on this and i need to hit a smaller button than on other windows. Or like the gnome default theme, the Titlebar is a lot bigger than the normal KDE (Plastik) window decorations.
    For Programs, which can really use it, there are CSD even with X11. So good support and a useful library would be cool. But it should not be the default, as it is for granted, that CSD in different programs (from different toolkits) will look at least slightly different, while SSD are always uniform and fitting my theme.
    Quick switching between CSD and SSD for windows (maybe with kwin rules to make it permanent) would be a nice feature as well. But as soon as a program starts to use non-standard CSD (like the media player with the buttons on the bottom), it needs code to adapt the interface for switching.


  2. I think your screenshots illustrate nicely when CSD can be good, but I have a more specific case where I think it would be great for most application – dialogs. Often, dialog boxes have system title, using whatever system font is, and another title inside the client area, typically using larger or bolder font, and that’s fairly repetitive. Leaving system title empty makes for funny window switching effects. It would be awesome if one could blend a custom dialog title with normal window decorations.


  3. Also regarding consistency:
    We have already libraries which make sure you can set the design of icons, sroll-bars, language, etc. system-wide. Why not add another library to go for coherent client-side decorations?


  4. “Consistency is lost; Windows might place buttons on the top, bottom, left, or right. Users would need to adjust to applications individually.”

    That already happens with plasmoids and we don’t think it is a problem there.

    Liked by 1 person

  5. I don’t see any really good reason in favor of CSD.
    I think point 2 “The decoration can be placed on any side. Applications like a movie player could hide decorations completely” is actually a disadvantage. It would result in unnecessary inconsistency.
    One possible advantage of CSD would be that they facilitate non-rectangular windows. However most of the cases that would benefit from this might be implemented as plasmoids instead. Also most themes that used non-rectangular windows did not have pleasant esthetics (e.g.: XMMS themes).
    If CSD decorations would ever be implemented I would strongly prefer the “SSD until otherwise permitted” model. And actually I think it would be best to have permissions per applications as I probably would want to allow only some applications to use CSD.

    As an alternative, in the case of the video player, wouldn’t it be possible to have semi-transparent SSD overlaid on top of the window content? Maybe even have invisible SSD overlaid on top of the video until they are hovered?
    Also, as mentioned above in the comments, maybe applications should make better use of dBus to add custom buttons in the title bar.

    As an aside, I really like the semaphore circle buttons. I would really like a dark Breeze theme but with the semaphore circle buttons.


    1. “I think point 2 “The decoration can be placed on any side. Applications like a movie player could hide decorations completely” is actually a disadvantage. It would result in unnecessary inconsistency.”

      Yes, I also think the movie player is not such a good example. A better example would probably be the/any web browser.

      “If CSD decorations would ever be implemented I would strongly prefer the “SSD until otherwise permitted” model. And actually I think it would be best to have permissions per applications as I probably would want to allow only some applications to use CSD.”
      I would go the other way around CSD by default and if it sucks enable SSD on a per application level. Otherwise you would never encounter what “insane” (good or bad) decoration someone thought of in their application.


  6. What always annoys me is that the behavior on the close (x) button is not consistent, i.e.:
    with Kget,Ktorrent,Clementine, Amarok(?) and other applications the “close” button doesn’t close the app, but instead minimize it to the systemtray.

    Can we please have here an appropiate “close” button from what the user can tell what will happen?
    (Dunno if this is possible with SSD?)

    Liked by 1 person

    1. I don’t think the close button is necessarily supposed to close an application. However it is definitely supposed to close the window. If there are more windows of the same application open, closing one should not close the application. Also if an application is active as a background service, closing the only window it has should not close the service.

      However, here are some ideas.
      Maybe this behavior should be signaled by a different close button.
      I believe at some point on Mac OS X (not sure if this is true in the current version) the close button behaved as follows:
      an “x” was displayed if the window would close when clicking it but a dot would be displayed if the window had unsaved content. It should be noted that in these versions of Mac OS X closing the last window of an application did not imply quitting the application.

      In KDE however, unless an application also runs in the background as signaled by the presence of a widget in the panel, closing the last window should also close the application. Therefore, maybe a similar behavior to the “x” and the dot in Mac OS X should be used to signify that closing the last window will not close the application. Or maybe we could have a new symbol (e.g.: an “*”) to enable us to have both behaviors: “x” is normal close, a dot is unsaved data, a “*” signals a background process.


  7. My biggest concern would be losing the extra functionality that KDE provides with its SSDs in particularly the keep on top button is fairly central to my workflow and a big part of the reason that KDE is my primary desktop. I don’t trust client programmers to provide this functionality.

    Liked by 1 person

    1. I don’t think it would be impossible to “inject” extra system buttons into the window decoration when using CSD, especially if, as mentioned in the fourth pro point, a strong CSD protocol/library. I clearly remember seeing such extra buttons on Windows systems.

      However I do believe it would be much more difficult to accomplish this with CSD, probably difficult enough to justify not switching to CSD.


  8. Hey Ken,
    thanks you for this comprehensive summary.

    One import (pro) point I’m missing, is that as a user one can actually customize the buttons in the title bar, as seen here for example (#2):

    So CSD IMHO is not only about loosing title bars, but also about user-customization.

    If I’m not mistaken this would only be possible with CSD, but what about dynamic decorations?

    Also I’m glad that wayland specifically target problems with CSD (freezing application). AFAIR this problem was always the strong point in aversion of CSD from the KWin maintainers.


      1. You have to enable the menu button in the Kwin settings and for all applications – you cannot do so in the application itself.
        So I don’t see how your remark helps here or you have to be more verbose.


  9. Loved the topic, thanks for your articles, Ken!

    Sorry for possibly ill-conditioned questions, I’m not a professional in this subject and also may missed some points in your post, english is not my native language:

    If this article is outdated a bit as you said, what the current state of KDE decoration system development directions? Is something changed significantly about CSD?
    When we’re talking about CSD vs. SSD and options to combine it to give user a choise, do you imagine it like “SSD and CSD-as-option, CSD-as-subcase” or in vice versa or this decoration options will be separed completely? Or is this an open or incorrect question?


    1. Right now there’s a third option being buzzed around the VDG and some KDE Devs outside of CSD and SSD, and internally it’s being called “DWD”, or “Dynamic Window Decorations”; and it’s something I’m very excited about. Essentially, DSD is a massive evolution of SSD where we get almost all of the benefits of CSD, and none of the problems.

      Currently I’m writing up my next post on DWD which I expect to push out sometime today or tomorrow. DWD is currently the frontrunner candidate to kow KDE might do these things, but it’s all in the concept phase and it’s still not know *if* it would be implemented, *what* in the spec were designing *would* be implemented, etc etc. Lots is in the air. But KDEs crazy-good developers have already begun crafting better solutions than CSD, and I’m excited to get the chance to present the initial concepts.

      Liked by 1 person

      1. Thanks kver,

        I saw that DWD mockup on plasma-devel and was wondering what was going on!

        As for the articles, I read your ideas in the forum and especially like your ideas when using Windows 10 for inspiration. Though, I also like the Takeoff menu (just like Apple’s Launchpad but that hasn’t been maintained in a while).


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s