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.


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

16 Replies to “About Windows and Widgets”

  1. Thanks for the detailed explanation Martin! =)

    Just wondering whether things could change when/if Wayland matures? More of a what is the long term outlook? Talking 2-5 years here. Stuff like allowing individual widgets to be windows if they provided a javascript effect file. E.g. user wants rss reader to slide out from left side as a transparent top most window if and only if the user is currently moving a window that would not over lap it (not the best example, sorry).

    By the way, your example “who would want the window manager to manage and composite all browser tabs” is actually something I’d been hoping for. Currently I have Windows Key + A as a shortcut to show all windows using the present windows effect, being able to have 1 key combination that shows all tabs from the current app using a present windows like effect, or all tabs from all apps would be a serious productivity booster. Don’t know if its possible though.

    1. Wayland gives us more possibilities but I expect for the next five to ten years we will need to be backward compatible to X11, so we cannot radically change if it breaks in X11.

  2. This is why KDE is the best — clear thinking.

    Also, I use XMonad as my WM, as do a number of people, and it would be sad if using Plasma required the use of KWin.

  3. The “plasmoids should not show up in window list” position is quite true but it got me thinking :

    Can’t we make use of plasma’s great api to create full-fledged apps (running their own process and window) ? I guess you’ll need to use dbus to talk to the dataproviders and you’ll have to find a good value for the plasmoid’s background, but it’s otherwise tempting for some application types.

    Maybe this exists already in the form of the plasmoidviewer but needs to be advertised better to the user (“create .desktop file to run this plasmoid independently” button ?).

  4. hi!
    thanks for explaining all the differences between all those components 🙂 it was a really interesting read 🙂

    what I am currently wondering if a good overview about all activities and assigned windows is planned? I know this has probably been asked before and I think I remember something like that is just not implemented because lack of manpower.. this is imho really missing – at least to me personally.. i guess this also belongs into kwin but needs deep interaction with plasma?

    long story short: could something like the activities in gnome shell be “”

  5. “easily” implemented as an effect?

    thanks for reading and your time to write this and kwin 🙂

    sorry about the split comment but i’m writing this from my tablet and hit beside the button 😛

    1. Activities in GNOME Shell are just virtual desktop and that we have. With Activities in KDE it becomes difficult due to limitations of X11, so for a proper overview we will need Wayland I fear.

  6. Hi Martin,

    I haven’t found anything like “contact me” on this page, so I hope you will read this.

    I have a problem with KDE in Kubuntu (in 10.10 and in 11.04 beta2) – A lot of Kwin effects doesn’t work (like blur, wobbly windows, and some other) with OpenGL (and with Xrender they dont work at all..)
    But with openSUSE on same computer all effects work without any problems..

    I don’t know if you can help me, but I hope you can 😉

    Best regards,
    Martin (aka bazdesh:D)

    1. Sorry my blog is neither a bug tracker nor a user support forum and I do not give private support. Please use forum.kde.org for user support.

  7. It is always a pleasure to read very rich informational text about technology without writer trying to do shortcuts and quested conclusions about it just because everything written should be “short and succinct” so others could read it in 15 seconds without actually learning anything or knowing anything.

  8. Thanks for the effort of writing this,
    I didn’t quite understand something, the apps draw it’s stuff in offpixmap and then the compositor draws this as a texture in the screen right?, but what about qml, it draws directly?

    1. QML in the end also draws into the offscreen pixmap as it is just a technology to render content of an app.

Comments are closed.