About Windows and Widgets

Last week a blog post on planetkde suggested to merge the functionality of Plasma and KWin. I quickly replied with a blog post that this is technically not possible and by the developers not considered. Jos asked me to write a blog post to explain this a little bit further. Who can say "No" to Dutch people and so here it is:

Windows and the Window Manager

First let’s have a look at Windows and the Window Manager. In the KDE Plasma Workspaces KWin is the Window Manager. That means it is responsible for managing windows. Ensuring that the right window has focus, adding window decorations, remembering the order of usage and much much more.

To the Window Manager a window is just a unique Id and completely transparent. The Window Manager has no idea what the window is about, what it looks like and why it is there. The window itself can set some properties which are used by the Window Manager to manage the window. This includes things like maximization, the desktop it is on, the icon to show and many more things mostly defined by the NETWM specification. Now the window system itself (currently X11) does not include all these things. For example the concept of virtual desktops is only provided by the window manager. For KWin a "window" is not a window at all. It is a "Client" to the manager. All windows (including the window manager) are in fact X11 clients. So the window manager does internally not manage windows despite its name but clients.

Many concepts are implemented several times. So a window is able to move itself as well as the window manager is able to move the window. In order to make this all work the window and the window manager must agree to some general protocol. This mostly works quite well, but in the end the window manager will have the final word. There are windows which are misbehaving and the window manager is able to fix their bugs.

KWin is a very advanced window manager and probably the window manager with most available features. This means that KWin gives you quite some candy to customize your personal window management, but nevertheless most just works due to common sense.

Windows and the Compositor

Next to KWin being a superb Window Manager it is also a compositor. The task of the compositor is to render the windows on screen. In legacy setups each window got assigned a part of the framebuffer and the XServer ensured that the areas are clipped correctly. When a compositor is around the window redirects the painting into an off-screen pixmap and the compositor renders the pixmap as a texture on the screen.

As the compositor has access to all window textures and is mostly integrated into the Window Manager we can put transformations on the windows. We can animate the appearance of windows, lay all windows out in a grid and much, much more. Without these "effects" there would not be much difference between the legacy way of rendering and the composited way. It’s just nicer looking with compositing and in general should be way more efficient (which may not be true with X11 but will be true with Wayland).

The compositor has no idea what it renders on the screen. In the end it’s just some texture rendered to the screen. In most cases it is just rendering a 2D texture in a 2D space. Very simple and very primitive OpenGL. The compositor tries to optimize the rendering by ensuring that only changed areas are rendered and that windows obscured by opaque windows are not rendered. In the end the compositor is just optimized to render windows. This is important to remember for the further understanding.

Plasma and Widgets

Plasma is first of all a framework to create desktop shells. We currently have the Plasma Desktop, Plasma Netbook and the Plasma Active shells. The shells can contain different widgets (aka Plasmoids) and lay them out. This layout is very different per shell. In the desktop shell it is possible to fully move the Plasmoids around, you can rotate them, scale them and do whatever you want. In the Netbook Shell on the other hand the Plasmoids are layed out like in a newspaper. It is much more constrained than in the Desktop shell. In the panel the constraints are even further: the Plasmoids are also constrained in size. Most are dropped down to an icon and expand when clicked. All this is achieved by having different containments for different fields of application. It is an important part of the support for Plasma’s device spectrum.

In opposite to the windowing system Plasmoids are completely controlled by the containment they belong to. They cannot move themselves, they cannot always change their size, they cannot start demanding attention or raising themselves above other Plasmoids. The system is quite different if we look at the details.

Plasma and the Compositor

To the compositor the Plasma shells are just a texture like any other as well which is rendered as a whole. As explained above the compositor does not know what is rendered at all and that there are Plasmoids. Currently the Plasma developers are working on libplasma2 which will make us of the new QML Scene Graph to do hardware accelerated rendering of the Plasma stack. This Scene Graph can be fast because it knows about the internals of the QML scene. Something the compositor would never know even if it were in Plasma. No matter how good our compositor would be it will never be on par for rendering plasmoids directly.

Plasmoids in the Window Manager

One of the claims in said blog post was that widgets are just a kind of windows and that therefore they should be known to the window manager. Plasmoids should be accessible through Alt+Tab, should show up in Present Windows and should just behave like normal windows. Now lets think about the implication. Right now I have two open windows and six open widgets in my panel including things like Kickoff and the systray. Who would want kickoff been shown in Alt+Tab? Who wants the latest Dilbert comic strip taking away valuable screen estate in Present Windows? Who wants to focus on the Weather Widget?

Of course there are widgets which are like "apps". But most are not. In general at least on the desktop it would be terrible to have Plasmoids available in the window manager.

Throwing around code bases

Now of course we could put Plasma and KWin into one application and create a monster. But what would be gained? The window manager component still does not know anything about Plasmoids neither does the compositing component, nor can the widgets component start to include windows. Just imagine you would try to allow that: putting LibreOffice Writer into the panel – great idea.

In order to get the window manager component to know about Plasmoids it is required to make Plasmoids windows. If we do that we don’t need to put the source code together – that can be achieved by the existing solutions. But doing that would pull in all the disadvantages of the legacy X11 system. KWin would need to be changed to know "this is a Plasmoid", KWin would need to duplicate all the special handling for the different containments, all other Window Managers would need to do the same or Plasma would only continue to work with KWin. As Plasma is just one big window the Plasmoids can make use of translucency without compositing. If they become windows they would need compositing to function at all. This is quite a change in requirements. Currently developing a new Shell is very fast, but when we start to do that in the window manager it would be complicated work, taking months to achieve what we now can have in days or hours.

About Merging Shells and Compositor

This month sees the first releases of two new Desktop Shells which are merged with the Compositor: GNOME Shell and Unity. I assume this is the motivation for the idea behind "Plasma and KWin should merge". Users might think that this is an advanced solution, but while preparing this blog post I tried to think up some advantages and I could not find even one. If you want to know about advantages you would have to ask GNOME Shell and Unity developers.

Both systems do to my knowledge provide nothing which cannot be achieved with KWin and Plasma. In fact I would go so far and claim that Plasma/KWin has a higher level of integration than Unity/Compiz or GNOME Shell/Mutter. We do that for quite some years now and are pretty good in doing this. And it gives us quite some advantages: You don’t have to use KWin to run Plasma, you don’t need compositing to run Plasma. The integration parts we develop can be used by other applications. Like the sliding animation written for Plasma is reused by Yakuake. The new shadow system is primarily developed to support widget styles and Plasma to set the shadow on windows. Our system is completely developed on the existing frameworks like X11, but is also compatible with Microsoft Windows, Mac OS X or in future Wayland. It is our believe that we can reach the same level of integration by defining a good API than to merge KWin and Plasma and to be fully open to any other window manager to work together with Plasma. Our custom additions are all well documented and mostly implemented at least by Compiz.

Summary

Even if it is not understandable for users there are differences between widgets and windows. In general you would not want the window manager to manage the widgets. To bring in a small comparison: who would want the window manager to manage and composite all browser tabs, in the end Facebook and GMail are just "apps", aren’t they?

KWin’s compositor is damn stupid and optimized for rendering 2D textures in 2D space. The QML scene graph is way better suited for rendering widgets than KWin’s compositor and making KWin render the widgets would be a large step back. From a technical point of view it does not make any sense to merge the two applications.

=-=-=-=-=
Powered by Blogilo