What if… KDE Started using Client-Side Decorations?

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.

Forward

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

Pros

• 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]

Cons

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

Notes

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!