Posted on

Web content embedded in KWin effects

Those who attended my talk about KWin Mobile at Akademy could see the new KWin effect which demonstrated that it is possible to embed web content in a KWin effect. Unfortunately nobody could see the highlight of the effect as Germany scored too early and too late. If somebody scored a goal a nice animation would have been shown. I just modified the effect to show the animation on startup to be able to record it. As always: sorry for the bad quality – recordmydesktop does not like me.

Direct download as ogv

And yes the effect is called "Kicker", as it connects to kicker.de to get the current score and in remembrance to a well known panel I kept the name. The effect is quite simple and is just something like 200 lines of code and it took me only one hour (first half of match Spain vs Chile plus the half time – yes I was confident that Germany will have a match during my talk) to implement the parsing of the current score and displaying it on the screen.

Each half a minute the effect connects to the remote site and downloads the html file. Using QtWebKit and some small reverse engineering it extracts the names of the two playing teams and the current score. These strings are combined and put into an "EffectFrame" – our high level API for displaying Plasma styled textures on the screen – and shown on each screen.

The effect also caches the current score and compares it with the previous one. If it changed we know that someone scored a goal and the animation is triggered. This animation (as seen above) uses another EffectFrame, but this time an unstyled. The animation will stop after seven seconds. In that duration the texture’s opacity value is constantly increasing and decreasing, so that you have a flash event. We have a high level API for that as well: KWin::TimeLine which wrapps QTimeLine in an API tainted for the usage in KWin effects.

The code is of course useless for KWin trunk as it is a really special feature and I don’t like the QtWebKit dependency in the effect library. Nevertheless I will import the code into our test directory as it is a nice example on how to use the EffectFrame and really showing how flexible our effect library is.

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

Posted on

Problems with Desktop Effects in RC1

In 4.5 RC 1 we hit several driver bugs again. We fixed a bug which caused blur not to work, but that fix intoduced different problems with some drivers.

It is possible that effects get suspended directy on startup. In that case try disabling the blur effect! If this does not solve the issue disable direct rendering in advanced effects tab.

There are also some problems with taskbar thumbnails and present windows. The previews might be upside down, too bright or the effect might be too slow. The same problem does not appear in desktop grid! This is caused by driver bugs already fixed upstream. So please update your drivers. You can disable the filter which is used for this in the global effects level, but this will also disable animations in Plasma.

We have bugreports for all those issues. If you want to comment on them please note driver and version.

Posted on

Akademy Talk: KWin Mobile

This weekend I prepared my slides for next weeks talk at Akademy about the mobile edition of KWin. I will talk about the reasons why we need a KWin mobile edition and why that will also benefit the desktop edition of KWin. For those who are not that familiar with KWin’s Compositing stack I will explain how the system works and where and how we can work on the OpenGL ES port. So that requires to illustrate the differences between the various OpenGL versions and what we have to do to get KWin’s codebase compiling on Maemo. As I have not yet started to implement the port (I think 4.5 is currently more important) I will also provide a roadmap on when we will see the pieces hitting trunk.

As my talk has a very special time slot I prepared a KWin effect on Friday evening for the talk. It’s a small but useful effect for the purpose and took me only about one hour to implement it and a nice effect to illustrate KWin’s flexibility, which is of course also part of the talk. Now I don’t want to spoil it, but I think it’s a nice and elegant solution to the problem that my talk collides with the second half of the quarterfinal Germany vs Argentina or Mexico. So please come to my talk and don’t stay in front of the TVs 🙂 I really love football and I can’t remember that I ever missed a German match at a World Cup. Given the way Germany played today, it will be really hard to miss the game. Who btw planned Akademy during World Cup?

I'm going to Akademy

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

Posted on

Freude mit Mesa

Die freien Mesa Treiber haben in den letzten Jahren tolle und wichtige Fortschritte gemacht. Mesa ist eine der wichtigsten Komponenten des freien Desktops heutzutage. Für mich als KWin Entwickler die wichtigste Upstream Komponente – auch wenn ich selbst Mesa Treiber nicht nutze. Von Mesa ist es abhängig, ob man Compositing standardmäßig hat, ob Blur eingeschaltet wird und andere wichtige visuelle Eigenschaften. Die Treiber sind aber auch unglaublich wichtig für die Geschwindigkeit des Systems. Viele (vermutlich alle) Beschwerden über den langsamen KDE 4 Desktop lassen sich auf den Treiber zurückführen (proprietär und frei). Dies ist gerade in 4.5 sehr wichtig, weil wir Blur standardmäßig aktivieren werden, sofern der Treiber es unterstützt. Wir müssen uns also darauf verlassen können, dass die Entwickler nur das in der API anbieten, was die Hardware wirklich unterstützt.

Ich werde nun einige der Probleme beschreiben, die wir so mit den Mesa Treibern haben. Das ist aber kein Rant – ich schätze die Arbeit der Mesa Entwickler und bin ihnen sehr dankbar und freue mich darauf bald einen freien Treiber auch auf meinem System einsetzen zu können (Nouveau unter Debian unterstützt noch kein DRI).

KWin führt eine Whitelist über die Treiber, welche Compositing unterstützen. Also wir parsen den Version String, den man auch unter OpenGL Version in glxinfo findet, und ermitteln daraus den Treiber. Wäre das ganze standardisiert, dann wäre es richtig einfach. Ein vorbildliches Beispiel hier von NVIDIA:

OpenGL version string: 3.2.0 NVIDIA 195.36.24

Solange ich jetzt für KWin arbeite hat das bei NVIDIA nie Probleme verursacht. Zuerst die OpenGL Version, dann Hersteller und Treiber Information. Bei NVIDIA aktivieren wir falls die Version mindestens 173.14.12 ist. Die freien Treiber machten sich aber scheinbar einen Spaß daraus die Treiber Information immer wieder an eine andere Stelle zu schreiben und unsere Annahmen wichtige Information steht z.B. an zweiter Stelle haben dann plötzlich nicht mehr funktioniert. Das führte dann dazu, dass der Treiber nicht mehr in der Whitelist war und somit Compositing nicht mehr aktiviert wurde. Mittlerweile haben wir einen extra Parser für Mesa Treiber. (Richtig toll wäre natürlich wenn man sich auf die OpenGL Version verlassen könnte, aber das ist unmöglich, denn es gibt auch noch den Software Rasterizer und der nennt sich auch Mesa).

Im 4.4 Entwicklungszyklus hatten wir das Problem, dass einige Mesa Treiber die Anwendung in den Tod gezogen hatten, wenn man versuchte die Version zu ermitteln. Das Problem hierbei ist, dass man einen OpenGL Kontext braucht um die Version zu ermitteln und der Treiber die Anwendung in den Tod gezogen hat, wenn man einen Kontext erstellt. Das führte dann dazu dass KWin nicht mehr startete, denn wir schauen immer ob Compositing unterstützt ist. Zum Glück haben wir Logik um Crashes zu erkennen und deaktivieren dann sicherheitshalber mal Compositing. Schwieriger wurde es in den Systemsettings. Dort ist die gleiche Logik um zu schauen ob man Effekte einschalten kann mit dem Resultat, dass Systemsettings abstürzen sobald man auf "Desktop" geklickt hat. Das ganze wurde kurz vor Beta 1 zu solch einem Problem, dass wir noch schnell eine Sicherheitslösung eingebaut hatten, die etwas zu weit gegriffen hat und in der Beta mal eben Effekte für einige freie Ati Treiber deaktivierte.

In 4.5 verlangen wir den Treibern nun bedeutend mehr ab. Wir haben zwei grafische Effekte, welche programmierbare GPUs erfordern. Zum einen den neuen Blur Filter, zum anderen einen Filter um bessere Thumbnails zu erhalten. Diese Filter werden natürlich nur verwendet, wenn die Grafikkarte das auch unterstützt. Zum Glück macht es OpenGL einem einfach: es gibt Erweiterungen auf die man testen kann. Unsere neuen Filter brauchen die Erweiterungen GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_framebuffer_object und GL_ARB_shading_language_100. Wir überprüfen, ob die Erweiterungen vorhanden sind und aktivieren die Filter – so weit die Theorie. Unsere Effekte haben eine statische Methode welche aufgerufen wird bevor der Effekt geladen wird. Diese Methode führt die Überprüfung aus und sagt "Ja, ich funktioniere" oder "Nein, ich funktioniere nicht". Wenn Blur meint, dass er funktioniert, dann informiert er Plasma sofort darüber und Plasma verwendet nun bedeutend stärker transparente Hintergründe für die Popups. Nun wird so ein Popup mit starker Transparenz angezeigt, Blur Effekt springt an und versucht ein framebuffer object zu bekommen und hoppla funktioniert nicht. Somit kein Blur und das Popup ist unlesbar, weil zu transparent (siehe Bug 240956).

Das heißt also wir können nicht darauf vertrauen, dass das was der Treiber sagt was er unterstützt auch unterstützt ist. Also müssen wir manuell die Überprüfung durchführen, was natürlich unnötige Rechen- und Speicherzeit für alle Nutzer verschwendet. Es wird nun beim Start versucht ein framebuffer object der richtigen Größe zu erstellen und nur wenn das funktioniert wird Blur aktiviert. Gut Blur ist nun deaktiviert, Plasma verwendet nicht zu transparente Hintergründe – Problem gelöst.

Naja nicht wirklich: die Grafikkarte behauptet ja, dass Blur funktioniert also muss es machbar sein. Die Erklärung liegt im direkten und indirekten Rendering. Die benötigten Erweiterungen stehen nur bei direktem Rendering zur Verfügung. Wir verwenden für Mesa Treiber jedoch indirektes Rendering, d.h. alle OpenGL Befehle werden zuerst an den X Server übermittelt und von diesem an die Grafikkarte weitergereicht. Also unser oben beschriebenes Problem liegt darin, dass der Treiber behauptet Erweiterungen zu unterstützen welche nur mit einem direct rendering Kontext verfügbar sind.

Also brauchen wir einen direct rendering context. Wir haben auch Code, der ermittelt ob wir einen direct rendering context verwenden können. Dieser überprüft auf die glX Version. Wir brauchen die Funktion glXCreatePixmap(), welche seit glX 1.3 verfügbar ist. Also alles unter 1.3 kann kein direct rendering. Naja stimmt nicht ganz über eine Extension ist das auch in früheren Versionen verfügbar und Mesa unterstützt die. Also Code geändert und auf die Extension überprüft und nun gibt’s auch direktes Rendern für Intel Karten und somit Blur. Mission erfüllt: glückliche Anwender.

Schön wärs. Nun haben wir direktes Rendern, aber es gibt Karten, die sind einfach zu alt für Blur. Ergebnis: KWin startet und schaltet Compositing sofort aus (siehe Bug 242113). Der Treiber unterstützt OpenGL Shading Language für Grafikkarten, die das ganz bestimmt nicht können. Nun sind wir also kurz vor den RCs und bei vielen Nutzern werden die Effekte nicht mehr funktionieren, weil der Treiber etwas unterstützt, was die Hardware nicht kann. Wir könnten nun einfach direktes rendern wieder ausschalten für diese Treiber, aber das würde auch Effekte zerstören, die keine Shader brauchen, aber direktes Rendern – zum Beispiel den Logout Effekt.

Auch wenn ich nun viel über Intel geschrieben habe, gibt es auch Probleme mit anderen Mesa Treibern. Z.B. mit dem Treiber für Ati R600 Chips im kommenden OpenSUSE 11.3. Bei diesem werden alle Thumbnails und Fenster in Present Windows auf dem Kopf stehen (siehe Bug 240354). Das Problem ist im Treiber Entwicklungszweig bereits behoben und wir wollten das daher eigentlich ignorieren – bis ich gestern openSUSE auf meinem Zweitrechner mit R600 installierte…

Nun kann ich mir Gedanken dazu machen, wie wir am Besten eine Blacklist erstellen, die einfach von uns und den Distributionen erweitert werden kann. Vor allem wie man Treiber wieder von der Blacklist herunterbekommt ohne mit jeder neuen Treiberversion die Blacklist aktualisieren zu müssen. Whitelist funktioniert nicht – haben wir ja schon, wissen wir dass es eine schlechte Idee ist. Und ich glaube wir verwenden eine Whitelist, weil Blacklist bei Compiz zu Problemen geführt hatte…

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

Posted on

Technical Limitations of Client-Side-Decorations

Sorry to blog again about Client-Side-Window-Decorations (CSD) but I was just made aware of the fact that you can open Alt+F3 in Plasma popups and that helped to produce this wonderful screenshot (sorry Eike and Plasma devs for destroying your apps in such a horrible way):

As we see all windows have KWin decorations and they should not have them. Yakuake has a kind of own CSD – you see the controls at the bottom. For Yakuake it’s totally fine to use the own controls as it has a very special usecase. Also all the Plasma windows should not have decorations as they are part of the workspace and by that not traditional windows.

So this is a technical and unsolvable problem for all windows which want to have CSD: the window manager may reparent the window and the window has no control over it. And this issue is really unsolvable, even if the NETWM specification would be extended it’s not solvable. There are window managers which have to reparent the window in order to function correctly. These are all tiling window managers. They have to be able to collapse the window into the decoration. Also KWin would never be able to support this correctly as we have features like window rules which can enforce a decoration for windows – no matter if the window wants or not. So to support it correctly we would have to break existing features which we don’t want (and KWin is a tiling wm, now). This also implies that we can never have a change to the specification as this would require consensus on all required parties and I think it is obvious that such a consensus does and cannot exist.

And just to show that this is also an issue for the only real existing CSD application out in the wild: I installed Chromium and it has two decorations:

This was the first time that I used Chromium. It opened up on Desktop 1, but I wanted to have it on Desktop 4 for the screenshot, so I rightclicked the Chromium decoration to move it to the different desktop and it doesn’t work. It doesn’t show the KWin useraction menu. Damn it, I was right, my concerns about CSD I blogged about in my last posts seem to be valid. There just is no consistency. Not to mention that it doesn’t have a menu button, no sticky button, the distance between maximize and close button is too small, clicking anywhere in the titlebar unmaximizes the window, the resize cursors are ugly and not the nice Oxygen one, the tooltips on the buttons have a different text to the one of KWin (no translation). Hmm kind of all my concerns from the last blog post are verified by this small example. When I wrote my last blog post I have never ever used Chromium. I only installed it once in a Lucid VM to illustrate the brokeness due to button layout. So all my concerns were not from looking at what doesn’t work in Chromium, but from what is clear to me what cannot work. So it was a pure theoretical post, while this is the experimental proof.

Please do not try to decorate Chromium with KWin decorations. It will most likely crash KWin!

I'm going to Akademy

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

Posted on

Blur Effect enabled by default

No, it’s not about window decorations 🙂

I just enabled the blur effect by default for the beta cycle. If your graphics card at least supports the extension GL_ARB_fragment_program (check with glxinfo) you should see the blur behind Plasma tooltips, etc.

Please give it a try and please report issues. A blur effect could cause slowness and artifacts and we would like to know of them before the release. I hope we won’t have to disable the effect again. Speaking of new cool effects: Fredrik did not only contribute a new blur effect, but also added an awesome shader to the taskbar thumbnails, so they should look much better. Unfortunately there is a small issue only present with NVIDIA driver so the improved thumbnails are only used for RGBA windows. I’m pretty sure we will fix this issue – perhaps even before beta tagging (I just have to recompile complete trunk to test some ideas). And sorry for not presenting a picture – my trunk is really broken at the moment 😉

I'm going to Akademy

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

Posted on

Open Letter: The issues with client-side-window-decorations

Hi Cody,

as you wanted to have a mail with all my concerns about client-side-window-decorations (CSD), here is a very long mail presenting all my concerns what will not be possible any more with CSD and why I think that these particular features will be impossible. The list is based on KWin’s current feature set.

Please see this mail as an offer to help. I could also just say “what do I care? We won’t support it in KDE, so let them destroy their desktop if they want.” But I do care. I do not want to blame your work, but I fear that you just don’t see the disadvantages and that CSD will be pushed onto the users without considering all pros and cons. That’s why I decided to CC the Ayatana mailinglist and publish this letter as an open letter on my blog. CSD is a topic that is important for every user and nothing we should discuss in a small group.

As you probably have noticed I oppose the introduction of CSD. I think they will have more disadvantages than benefits to the user. In fact I do not see any pro argument for CSD. All the pros I found during hours of research on some wiki pages, GNOME Shell design documents, blog posts, etc. do not give one valid reason. In fact most of the pro arguments are already present in KWin. I will refer to the arguments for CSD again at the end of my mail. If there are any other pro arguments not recorded on the Wiki page, please publish them.

  • Consistent window decorations: This in fact is my greatest doubt. The current situation is that all windows have the same window decoration. For CSD to work applications have to be changed to support them. This will render the changed applications using CSD while all other applications are decorated by the window manager. I think it is impossible to have the same behavior for both CSD and wm decos. I think there are lots of legacy applications which cannot be changed, for example Amarok 1.4 which is still used by many users even in GNOME. I doubt you will be able to change Qt 3 to use CSD. My bigger concern is that we will end up with applications shipping their own style and doing their own kind of decorations. So we end up with situations like one window has buttons on left, one on the right, one in order close, maximize, minimize, the other in close, minimize, maximize, etc. Why do I have this concern? Well let’s just look on the Microsoft Windows desktop to see what proprietary applications tend to do when they get the chance to influence the decorations. I expect the same thing to happen on free desktops as we already have such style issues with proprietary applications. For example Google Earth and Opera both do not use the default Qt style but ship their own one. In case of Google Earth it’s even bundled with an own Qt copy so you cannot even overwrite the setting. I also expect that “free” software will do such issues – to get a famous example: launch Chromium in Ubuntu Lucid. It has the decoration handles on the wrong side. And for the user experience this is very bad.

    Now I want to explain why it is impossible to have consistent decoration handling between CSD and wm decos in the case of KWin. KWin has a default button layout (Menu, sticky on the left, (help), minimize, maximize, explicit spacer, explicit spacer, close on the right), which is hardcoded into the source code. The layout could change at any time if the KWin developers and the usability team decide that there is a more usable layout! Each decoration plugin is allowed to overwrite the default button layout (which is done by the default decoration Oxygen). In case of my theme engine Aurorae each theme is allowed to overwrite the default layout. However, that’s not all – the user is allowed to customize the layout. So to get it right CSD would have to check which decoration plugin is loaded and would have to know how the button order is defined. As this layout is also hardcoded this is just impossible. The CSD would have to guess KWin’s default layout and check KWin’s settings if the user has changed the layout. I doubt you want to add KConfig support to GTK CSD. The whole situation becomes more complicated if a user is using Compiz in KDE. In that case the CSD would have to check if kde-window-decorator is used, which would require to parse the KWin settings or to read Emerald or whatever. Let’s just forget about other window managers as the point is already obvious: a client-side-decorated window cannot know how the layout of decoration buttons in the window manager decorations is set. In order to get CSD working properly all windows would have to use CSD and as said before this is just impossible due to legacy applications. There is one more important thing to know: KWin guarantees binary compatibility for the decoration API for the lifetime of KDE platform 4. We cannot change the decoration API in order to support CSD without breaking BC and all decorations!

  • Closing hung applications: Currently there is an easy way to close a hung application. You click the close button in the decoration and the window manager will notice that the application does not response any more and will offer to forcefully close the window. With CSD this is impossible. The close button is part of the hung application and so the click event cannot be recognized. I do not expect users to know shortcuts like ctrl+alt+esc to forcefully close a window and so they will be stuck with an unresponsive application. In case the application is caught in an endless loop this would render the system unusable and an unexperienced user has only one choice: force the system to reboot by the power switch.
  • Consistent user actions between decoration and task manager: KDE keeps the context menu of the decoration and the tasks applet in sync. It uses the same order of options, the same look&feel and the same wording. If a change is required it has to be manually submitted to both menus. I can’t see how a non-KDE application wants to be in sync with KDE’s context menu. I don’t think I have to mention that the context menus are currently all using a Qt style. As we all know GTK does not look like Qt in KDE. So there will be a visual inconsistency in context menus. (Seems that I mentioned it nevertheless) Btw different window managers offer a different set of features. So one menu for all window managers just doesn’t work.
  • User actions menu in general: This brings us to the next topic: What happens in response to right clicking a CSD. KWin by default shows the user actions menu including KWin internal options like window tabbing (if the decoration supports it), opacity and the option to configure the window behavior. Will a CSD be able to populate KWin specific options? How do I access the window behavior settings from a client side decoration? What happens when I use the shortcut to show the menu (alt+f3) which is handled by KWin? Why is it a different one for CSD, while it is the same for all other windows? Another case of inconsistent behavior.
  • One place to configure mouse actions: Another point directly motivated by the one before: what actually happens if I left, right, middle click the decoration. KWin provides completely configurable actions in the user interface. I wanted to present all possible options but there are too many, so I just write down which different actions are supported:
    • doubleclicking the decoration (just titlebar, not border)
    • mouse wheel the decoration (just titlebar, not border)
    • different settings for what happens when you left/right/middle click the decoration (titlebar and border) for active and for inactive window.

    The settings include things like open context menu, place window to the back, raise window, start window tab dragging, etc. etc. If you want a complete list of options please have a look on the settings. I do not see how a CSD can know about what is configured in KWin. This just has to result in inconsistent behavior and complains by users because right click opens the context menu and does not move the window to the back.

  • Different settings for the maximize button: KWin supports to configure the action which should be performed when left/middle/right click the maximize button: maximize horizontal, maximize vertical or maximize both. This is an issue where I ask myself: will this be supported at all and of course the same as above: the CSD cannot know KWin’s setting.
  • Differentiating between window and decoration: KWin currently supports different actions when you click the window and the decoration. E.g. it’s possible to raise a window by clicking the titlebar, but clicking the window content will raise and activate it. As there is no decoration provided by KWin any more this functionality would be lost completely. Removing title bar actions means that many useful features are lost, like wheel on titlebar raises windows or changes opacity. You don’t want that functionality in the window as the window needs the wheel event to scroll the content.
  • Window Shading: window shading is a tricky operation for CSD and I don’t see how you could get it working. I just had a look at the KWin code and it seems like window shading requires wm decos. The window get’s unmapped and only the deco is shown. I don’t know how KWin would behave if the window is undecorated, but I think that window shading is not possible any more. Even if it were possible we would have again a very inconsistent behavior as the decoration handling would switch from client-side to wm. To this point I want to quote the NETWM spec:

    Some desktop environments offer shading (also known as rollup) as an alternative to iconification. A shaded window typically shows only the titlebar, the client window is hidden, thus shading is not useful for windows which are not decorated with a titlebar.

  • Adding additional buttons: KWin allows to add additional buttons to the decoration. Our default decoration provides buttons like keep above, keep below and shade. By default a sticky button is used. Our default layout has more buttons than all the decoration themes provided by Ubuntu. I am very concerned that CSD will not have the same set of buttons and that it is not possible to globally add/remove buttons as it is possible today. The reasons why that is not possible have been presented in the fist topic.
  • Remote X-Clients: If a session includes remote X-Clients using CSD these will use the GTK style of the remote system resulting in inconsistency. Currently this works fine as remote clients are treated like every other client.
  • Shadows: A CSD window will not have a shadow provided by KWin. Shadows are an important feature to distinguish the active from inactive windows. As it is not obvious why we cannot provide shadows for CSD windows I have to explain how the shadow works. Since 4.3 the decorations are able to paint shadows. This is a KWin internal thing: the decoration provides a padding region and this region is internally ignored for things like window snapping and to ensure that the shadow is not clickable (as the decoration is a widget this is important). Currently Oxygen and Aurorae are the only default shipped decorations making use of this feature. If a decoration does not provide it’s own decoration the shadow effect will draw a shadow. There is exactly one variant of shadow to suit them all. And this is just impossible. If you have a dark widget theme a dark shadow is a bad idea. The shadow is a texture which is painted below the window texture. This means if the window has an alpha channel the blending will be done to the shadow and not to the windows below which looks really bad. Just search for images showing a translucent Konsole in KDE 4.x with x < 2. Now I still haven't mentioned why a CSD decoration won't have a shadow. We see why it would be a bad idea (as you want to have an alpha channel) but there is more in it. I assume that you want to have round corners in your decoration. So you have to set a shape or your corners will be clickable (bad idea). If a window has a custom shape the shadow effect will not apply the shadow to the window as it doesn't know the shape. We could just paint the shadow but in most cases it would look really bad or we could find some tricky logic that looks where the window is painted and how to draw the perfect shadow. We haven't found a solution to this problem during the last 2,5 years and I do not expect that we find a solution to this issue in the future. It would require shaders so it is not an option which would work for all users and I think that the shadow inside the decorations is the better approach. Oh and what we currently do to decorations cannot be done by windows as that requires changes in the NETWM protocol and in the window managers. As you might guess I am not interested in spending time on adding stuff to KWin required to make CSD work ;-)
  • Tooltips: KWin has a setting to provide tooltips when hovering decoration buttons. I do not see how this can be consistent between CSD and wm decos. Obviously the tooltips won’t look the same as the one is GTK and the other is Qt. Furthermore I don’t think that the titles of the tooltips can be the same and even if they were the same I don’t think that they would be translated in the same way in all existing languages. This is another case of inconsistency.
  • Netbook mode: KWin has a special netbook mode to hide the decoration for maximized windows when the netbook mode is chosen. I do not see how a GTK CSD window can honor such a setting.
  • Accessibility: KWin provides globally customizable border sizes. Some decorations (Oxygen and Aurorae) also provide customizable button sizes. Both sizes are dependent on the decoration or in case of Aurorae from the theme. So there is no way for a CSD to get the same border size. I think accessibility is a very important feature. In fact Aurorae allows to change two settings: border size and button size, everything else is defined in the theme.
  • Window Tabbing: KWin’s window tabbing is part of the decoration API. A window which does not have a decoration cannot be included in window tabs. So it destroys a useful functionality.
  • Numbering in window title: KWin provides a feature to number the windows. So if you have two windows foo, the second will be called foo <2> in the decoration. This is specified in the _NET_WM_VISIBLE_NAME hint, so in fact it is possible to implement this feature.
  • Forcefully adding buttons: KWin allows to add buttons to window decorations even if the window does not provide the action. E.g. if a window is not closeable we can force it to be closeable by a window rule to get the button back. My concern is that with CSD the application would not add the button again as it has in the internal logic that there is no close button for this window. The same obviously applies for maximize button, etc. KWin allows to overwrite any of the settings a window might set, which is the right of a window manager.
  • Changing themes: KWin and also Metacity allows to change the themes for all window decorations at one place. If we introduce CSD we have some applications having a wm themed decoration, some applications with a GTK themed decoration and some with a Qt themed decoration. If we introduce CSD the current setting dialog is more than confusing and would have to be removed. Btw I just want to mention that I rewrote the KWin decoration selection module for 4.5. More on the work going on in KWin regarding decorations later in this mail.
  • Probably much much more I just have not thought about yet or forgotten to mention in this list. I think the point is obvious: we have a well established system and there have to be good reasons to change something so fundamentally to the window behavior.

This brings me to the next topic: The pro arguments of CSD. The point is: I do not know of one pro argument. I thought a lot about why do they want CSD and all I can come up with is that you want RGBA windows, but this is no reason to go for CSD. This is perfectly possible with KWin since 4.4, so I do not see why you would want to go for CSD. If there are other reasons please communicate them. And please use this list as a starting point to step back and think about what you want to achieve and if CSD is the right approach to achieve it. If all you want is RGBA it will be easier to extend Metacity to support it or (in case of Canonical) switch to a default window manager which supports it. I assume that Ubuntu 10.10 will be shipped with Compiz 0.9 so you could get a window manager which supports both non-compositing and compositing and alpha in the decoration. And I just want to mention that Ubuntu has another window manager in the main repository which supports all the required features, but I don’t expect Ubuntu switching to KWin as the default window manager 🙂

So let’s look again on the list of pro arguments on the GNOME wiki:

  • Fix issues with the non-reparenting window manager Compiz: Not an issue any more as Compiz 0.9 is a reparenting window manager. Nice this one is done
  • Have a good reason for RGBA: As mentioned KWin supports this by extending the window decoration behind translucent content (http://blog.martin-graesslin.com/blog/2009/11/window-decoration-behind-translucent-windows/). So you could go for this approach. Just as a note: KDE does not make use of this feature, but it is supported. so not valid.
  • Possible performance improvements: please test if it is really an improvement. Considering KWin’s approach to RGBA decorations I don’t think it is. Just the idea that there could be improvements is not a valid argument.
  • single source for theming the application and decoration: that would be nice, but as my concerns in this mail show, the opposite is most likely true. I love that idea, but could you please first fix GTK to use the Qt style in KDE environment? That would be nice from an integration point of view. So not valid.
  • Get gtk+ working on Wayland: I don’t see how Wayland can be an argument for CSD. Could we consider Wayland as unimportant till it is looking like something is actually going on? I checked the commits in 2010 in the public git repository and well it looks like KWin has more commits per day. It’s nice that you think of the future, but please don’t use it for argumentation. So also not valid.

And that’s the problem I have with CSD. I have a very long list of issues, so to say the cons and there are no valid pro arguments. I like innovation, but I completely dislike innovation for the sake of innovation. I also dislike to break with existing solutions. If we break existing solutions there has to be a good reason for it. And here I am still missing the good reasons.

Now last but not least I want to present some of the work going on in KWin for decorations. Decorations are currently the most actively developed part of KWin. In 4.3 we added support for translucent window decorations, in 4.4 we added support to paint decorations behind translucent windows and we received window tabbing support. Currently there is a very active development in our default decoration Oxygen and in my theme engine Aurorae. I initially implemented Aurorae for 4.3 to have a decoration which makes use of translucency. Since 4.4 Aurorae is part of KWin and I have spent much time on improving it for 4.5. So it is now based on the Qt GraphicsView framework, it allows to place the decoration to the left or right to make better use of vertical screen space. The theming support is improved, so it’s possible to have one common background for a button group. That’s something the Canonical designers might like – in fact this feature is inspired by the brokeness of the new Ubuntu theme during the beta phase of Lucid 😉 I started to work on a designer application for Aurorae themes. The decoration configuration module has been reworked and allows to directly install new themes for kde-look.org through GHNS. I have some more ideas for Aurorae in 4.6. So I want to make the decoration auto-hiding for maximized windows to save more vertical space. I am thinking about adding a special element for fullscreen applications to easily switch back to normal mode. I plan to make Aurorae a common library which can be used not only in KWin but also directly in Compiz. In fact the Aurorae code does not have a KWin dependency any more. This was required to get the designer work and is also used to render the previews in the configuration module. I think it would be a pity to abandon all this work and to replace it with something that is not on par from the feature side of view. And AFAIK also in Metacity there is some work going on to design a new theme format.

So as expected this mail has been rather long and I think I missed probably have of the points I had in mind. Thanks for taking the time to read it and thinking about if CSD are the right way to go. If you have questions how to get your wished features to work with existing technology please do not hesitate to ask and I will try to help you. I am sure the Compiz devs will also offer their help to get required features implemented.

Regards
Martin Gräßlin

Posted on

Eingefroren – Blick zurück auf KDE SC 4.5

Heute ist es mal wieder soweit: KDE SC trunk wird für alle Feature Commits für die im August erscheinende KDE Software Compilation in Version 4.5 eingefroren. Ab morgen dürfen also nur noch Bugfixes eingespielt werden. Es ist immer wieder ein spannendes Ereignis zu sehen wie die ganze Community die letzten Tage vor dem Freeze gemeinsam daran arbeitet möglichst viele Features noch fertig zu bekommen.

Für mich ist es auch der richtige Zeitpunkt um auf den Releasezyklus zurückzublicken und zu schauen was ich gemacht habe. Da die meiste Zeit dieses Zyklus mit der Endphase meiner Masterthesis zusammenfiel habe ich natürlich nicht ansatzweise so viel umsetzen können wie im 4.4 Zyklus. In den letzten Releases hatte ich hauptsächlich an den Effekten gearbeitet, in 4.5 jedoch kaum noch. Unsere Effekte sind mittlerweile in einem sehr guten Zustand und sind größtenteils nur noch im Maintainance Modus. Als einzige Änderung meinerseits gibt es im Desktopgrid die Möglichkeit Desktops hinzuzufügen und zu entfernen, also eine Art GNOME Shell light 😉 (Man nehme das nützliche und lasse das unnütze weg). Von der technischen Seite ist es eine sehr interessante Änderung, da es der erste Effekt ist, der nun Nutzerinteraktion erlaubt. Dies muss nun etwas angepasst und verallgemeinert werden, so dass Benutzerinteraktion in allen Effekten möglich ist (Schließen-Schaltfläche in Present Windows, Kickoff/KRunner öffnen in Übersichten, etc. etc.).

Am meisten habe ich in 4.5 an den Fensterdekorationen gearbeitet. Für den Nutzer am angenehmsten dürfte eine Änderung sein, die ich für 4.4 nicht mehr fertig stellen konnte. Das KControll Modul zur Auswahl der Fensterdekoration wurde komplett neugeschrieben (stammte noch aus KDE 2 Zeiten) und zeigt nun in der Liste jede Dekoration direkt als Vorschaubild an. Aurorae wird dabei als Dekoration gar nicht mehr aufgeführt, sondern jedes Theme wird als eigener Eintrag aufgeführt. Wählt man solch eine Dekoration, so wird von KWin vollautomatisch im Hintergrund Aurorae ausgewählt. Für den Nutzer sollte es nun nicht mehr erkennbar sein was eine native und was eine Aurorae Theme ist. Dieses Vorgehen erlaubt uns auch einen weiteren Trick: GetHotNewStuff für Dekorationen. Weiterhin ist es natürlich nicht möglich native Dekorationen herunterzuladen, aber man kann direkt Aurorae Themes herunterladen, welche dann in die Liste übernommen werden.

Aurorae war generell der Bereich der am stärksten von mir überarbeitet wurde. Ich habe schon vor einiger Zeit festgestellt, dass das Software Design nicht weiter skaliert und viele der Vorstellungen der Designer sich nicht umsetzen lassen. Ich hab daher große Teile Auroraes komplett neugeschrieben. Als "Abfallprodukt" ist dabei der AuroraeDesigner rausgesprungen. Eigentlich ein Entwicklungswerkzeug für mich um Änderungen schneller ausprobieren zu können ohne KWin ständig neu starten zu müssen, jedoch auch ein Werkzeug für Designer um ihre Theme zu testen.

Neben dem Rewrite konnten auch einige neue Features eingebaut werden. So habe ich letztes Wochenende in einer Last-Minute-Hacking-Session Window Tabbing eingebaut. Schon vorher wurden einige meiner "Experimente" wie Dekorationen links/rechts/oben/unten eingebaut und verschiedene Erweiterungen für die Designer. So kann man nun maximierte Fenster gezielt gestalten und hinter die Schaltflächen kann ein gemeinsamer Hintergrund gesetzt werden.

Ein Freeze ist natürlich auch ein guter Zeitpunkt um nach vorne zu blicken: was plane ich für den 4.6 Releasezyklus. Hier habe ich mir zwei Themenkomplexe gesetzt:

  1. Aurorae Feature Completeness: all meine Experimente einbauen und eine Compiz Portierung. Aurorae selbst hat keine direkte KWin Abhängigkeit mehr. Die KWin Dekoration ist nur eine sehr dünne Schnittstelle zwischen KWin und dem Aurorae Kern. Daher sollte es sich auch in Compiz integrieren lassen.
  2. Ein OpenGL ES Compositing Backend entwickeln: ich möchte KWin auf meinem Nokia N900 zum Laufen bekommen und werde dazu den OpenGL Compositing Bereich relativ stark umbauen, so dass es auch mit OpenGL ES lauffähig ist. Damit ich das ganze auch mache, werde ich auf der diesjährigen Akademy eine Präsentation zu dem Thema halten.

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

Posted on

Follow-up on client-side-decorations

As there has been quite some reactions on my recent blog post explaining why client-side-window-decorations are a bad idea I decided to answer some of the comment in a new blog post.

First of all I want to say that Canonicals idea for windicators is not the reason why I dislike the idea of client-side-window-decorations. I am afraid of this development for quite some time and wanted to write a blog post on that issue for quite some time. German readers of this blog post might have noticed that the current issue of freiesMagazin contains an article I wrote in March on that topic. The fact that it was published almost the same time as Mark’s windicator announcement is a lucky coincidence. So windicators are just the catalyst for writing the blog post. While I don’t think their idea is a good one (in fact I wanted to announce Plasmoid support in Aurorae as an April fools article) I do not oppose the development in general. I just oppose that it is now another (false) reason why we need client-side-window-decorations. Yes it is possible to implement something like that in the current KWin decoration API and I think our recently added support for window tabbing should be proof enough that window decorations can be extended.

In my blog post I mentioned that client-side-window-decorations will destroy consistency. Apparently many readers thought I mean visual consistency. While this is an issue I don’t expect fixable (if it were fixable, why is my Mozilla Firefox looking different to all other apps?), it is not what I meant. I am afraid of the much worse behavioral inconsistency. Just try using Chromium in Ubuntu Lucid and you will know what I mean. The obvious counter-argument to that concern is that the Qt and GTK style will be patched so that all apps will share the same decoration. But will this work? I doubt it. What about all my legacy, proprietary applications I just cannot patch? They will have the window manager decorations. What about applications the authors don’t want you to patch because it’s destroying their brand? This is a real concern and to me the consistency in behavior is more important than visual glitches or a little bit more space due to removing the status bar. What I also want to note is, that KWin has many more features regarding decorations than e.g. Metacity. This is I am afraid that GTK+ decorations will at maximum gain feature comparity with Metacity.

Cody Russel commented and said that we just should relax:

Settle down, people. This is just an experiment, and if it turns out that it doesn’t work well or doesn’t gain us anything then we just won’t use it.

Now Cody, I have to disagree. Now it’s the time to raise the concerns. Canonical is starting to build up a new functionality on it. If we do not make clear that client-side-window-decorations are a bad idea this "experiment" will be in 10.10. Canonical has unfortunately a history of ignoring all concerns and shipping their utterly broken concepts and trying to upstream their strange changes (just remember replacing the suspend notification by a nag-screen). Sorry that I do not buy your "it’s just an experiment".

Cody continues:

The reality is that client-side decorations is something I proposed, and there has been interest in it from Intel, Red Hat, Google, and now Canonical. I’ve even mentioned it to someone at Nokia once and he seemed at least interested in it.

It’s nice that you talked to all those corporations. Apparently you failed to communicate with the KDE, Compiz (and GNOME?) community. The fact that these corporations are interested does not turn the feature into a good idea. Sorry, I couldn’t care less to which corporation you talked.

I honestly don’t think this is going to affect you in any way. If you’re running KWin or whatever, and you run a GTK+ application under it.. just don’t run a theme that enables client-side-decorations if you’re concerned about how it’s going to fit into your environment.

This is a nice one. Is this a promise that I will never get a bugreport because an app seems to be broken because of client-side-window-decorations? Does that mean that I can reassign each bug to you? I do not just think of me, I’m thinking of my whole userbase and also of GNOME’s userbase. And introducing client-side-window-decorations is calling for trouble. Just an example we have with Chromium: since KDE SC 4.4 we unmaximize a window when it is moved. KWin has a drag delay, Chromium doesn’t. So clicking anywhere in the decoration area will unmaximize the window. This is an application bug, the developers don’t want to fix. You see, I have valid concerns to such ideas.

Now on planet GNOME there was one direct reaction to my blog post trying to invalidate each of my arguments. I spare you the details by just pointing out one of the "it’s not true" points:

Window rules like always show a close button even if the window is not closeable: Working around broken apps? Fix your apps…

Is that really the level of argumentation? That sounds like someone did not find arguments. But I understand: Metacity does not provide window rules, so you are not able to see the advantage in features you don’t know. As mentioned above with the Chromium bug: sometimes bugs are not fixable, especially if it is your legacy proprietary application.

The blog post contains some more "reasons" why we need client-side-window-decorations.

Tear-free window resizing (when the client is doing the resizing, with a proper resize grip for example)

I have tear-free resizing and Oxygen can provide a proper resize grip. Even if it were not possible: shouldn’t we fix the window manager? *scnr*

Better integration of resizing within applications (say "zooming" when going to fullscreen

Erm right, never noticed this missing usecase. Takes me half an hour to implement that as an effect which will be fast and not slow due to constant resizing of the window content.

Proper way to do tabs in titlebar, a-la Google Chrome

A right, that’s why KWin has window tabbing 😉

Window-as-a-document/object

Why do we need client-side-window-decorations for that?

The best thing in this blog post was the link to the GNOME Wiki where we can find all the real arguments.

  • Fix issues we get with non-reparenting WMs like compiz that transform the window and the user can see an ugly polygon edges between titlebar and app

When I was reading this I got such an laugh-flash that my roommate was asking what happened. First of all you should fix your apps™, second you should do your homework: Compiz will be a reparenting window manager in the next release. So reason number one is invalid.

  • Have a good reason to push for rgba windows 🙂

WTF? Honestly? You want to break all applications just to get rgba? I know Metacity does not support RGBA in the decoration, so fix it™. The way KWin added support for RGBA should work for Metacity as well. We even added a new EWMH hint so that the window can request that the decoration paints the background, if you want a translucent theme.

  • Possible performance improvement in reparenting WMs where there is currently a mismatch between client/decoration visuals?

So you are not sure if it will provide improvements? If you go the KWin way it should be fine

  • single source for theming the application and decoration

Yes would be nice to have and exists. It’s called QtCurve

  • Get gtk+ working on Wayland

Wayland? Come on, get real arguments. We can talk about that in erm let’s say ten years?

So that’s it. There are not more arguments pro client-side-window-decorations. So I read through all these documentations and arguments and to quote Faust:

Da steh ich nun, ich armer Tor!

Und bin so klug als wie zuvor

I still do not see any reason why we should break with a concept which has worked properly in the last 20 years or even longer. Why replace something working with something which cannot work, which will cause many, many problems. I am looking forward to a discussion on these issues. I just hope we won’t find it in the next Ubuntu release and all users have to suffer from a misconception during the design phase.

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

Posted on

Why you should not use client-side window decorations…

So finally I know who had the idea of client side decorations: it’s Canonical. Why didn’t I think of it before? I have been aware of the fact that GTK wants to do client-side window decorations since it was mentioned on the EWMH mailinglist and I think it is a completely stupid idea which has the potential to destroy one of the most important advantages of the free desktop: a consistent client handling.

For those who don’t know what client-side window decorations are: the window client, that is the application draws the titlebar instead of the window manager as we have it today. I will discuss the disadvantages of this approach later in the post.

Up to today I have not found any valid reason why you should even think of client-side window decorations. Well Mark provides a reason: windicators. A kind of Statusnotifier inside the application. As the window decoration cannot do it (today) it is the logical consequence to remove decorations. It would not have been possible to extend an existing framework.

Well to be honest we get request to add arbitrary functionality like a mute button in the decoration about once a month. And we always say no, because it is not possible as there is no common interface. With something like a dbus protocol these "windicators" would be possible, not that I’d think it’s a good idea.

But apparently Canonical did not think of extending the existing functionality, but to remove the functionality. There is already one application which uses those client-side-decorations and it’s called Chromium. If you want to have an impression on the consequences of client-side decorations, just go through all open KWin bugs and look for the mentioned applications. I think you will know which one is currently my most loved application from a wm-dev perspective.

So what will we lose due to client-side decorations?

  • Consistent behavior between all applications no matter if it is a Qt or a GTK or $Toolkit application
  • Window Tabbing (KWin specific)
  • Window rules like always show a close button even if the window is not closeable
  • Accessibility features like big border and button sizes for all windows
  • Easily changeable window themes
  • Shadows which are part of the theme (KWin would not paint shadows for a client-side window-decorated window)
  • …

In general up to now I always read of the same advantages, like it saves space. But that is just not true. The KDE Plasma Netbook Shell illustrates in a perfect way how we can use space more efficient. I also have some ideas for Aurorae like decorations on the left/right (implemented) and autohiding decorations for maximized windows (due to upcoming feature freeze probably 4.6). Also I think that Rekonq is a nice example to show how we can use the limited vertical space in a well thought way. Yes I agree that statusbars are somewhat useless and outdated, but just look on Rekonq’s clever behavior for statusbars. Or think of KDevelop’s (congrats to the release, I love your application) usage of the empty space next to the menu bar. Of course we have some problems of space wasting, but that is no reason to break with working solutions.

To summarize: client-side-decorations will destroy more than they benefit. Please devs at Canonical, please think of the consequences. Please think about the fact that you have to change all applications, please think about that your Upstreams might not like the idea, please think about more than one or two years. Please have a look on the Microsoft Windows platform and the totally inconsistent window behavior. Think about how the free desktop could look like if we start to use client-side decorations allowing each program to enlighten us with their preferred idea of window management. If we get client side decorations, Mac OS will be the last useful system with a consistent behavior and I think we can agree that this is not a nice few. Please remember that a window manager is called a manager, because he manages the windows. I do not like to see mistakes fixed ten years ago in the window managers to be present again (what about a drag delay in moving windows on free space in the new Ubuntu GTK theme?).

As far as I followed the small discussion on the EWMH specific mailinglist, the idea is that the window manager has to announce that client-side-decorations are allowed. This means that we as KDE have the option to not implement this "feature" so that our desktop will still have a consistent user experience. It’s also our chance to raise the concerns again when it is discussed on the mailinglist in more detail (which has not happened, there has not been any discussion, if we want client side decorations or not). Given that Metacity is developing a new theme engine, I hope that also the GNOME community opposes such ideas.

I also hope that Canonical will start to discuss such ideas with their upstreams. There has been no discussion about NotifyOSD and their removal of actions. With the "Panel Indicators" I though that Canonical mastered this part of their history and starts to collaborate. Now it looks like alea iacta est again, without any chances for the upstream to raise concerns 🙁

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