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

Posted on

Eindrücke von Maemo

Ich hab mir vor ein paar Wochen ein Nokia N900 mit der Debian basierten Distribution Maemo zugelegt. Für die täglichen Fahrten nach Heidelberg wollte ich ein Smartphone mit Internetzugang haben. Die Auswahl ist dabei ja etwas eingeschränkt zugespitzt zwischen iPhone, Symbian-basierten Handys, Android und Maemo. Außer Maemo sind eigentlich alle Handybetriebssysteme mehr oder weniger geschlossen. Da ich natürlich mehr Interesse an einem System habe als nur die Nutzung als Internetbrowser musste ich nicht lange überlegen welches Handy ich mir zulege 😉

Mein langfristiges Ziel ist es die KDE Bemühungen für Plasma Mobile zu unterstützen und KWin auf dem Gerät zum Laufen zu bringen. Bisher habe ich mich damit noch nicht beschäftigt, da ich erst den in 10 Tagen anstehenden Feature Freeze für KDE SC 4.5 abwarten will. Natürlich habe ich mir schon Gedanken dazu gemacht und werde wahrscheinlich auch auf der diesjährigen Akademy einen Vortrag zum Thema halten.

Bei der Nutzung des Systems beobachte ich sehr genau den Fenstermanager und kann daraus schon folgern, dass von der Benutzung her KWin problemlos für ein Handy geeignet ist. Im Vergleich zum Vorgängermodell ist der Fenstermanager nun ein Composited Fenstermanager und das kommt der Benutzung sehr entgegen. Das Wechseln zwischen Anwendungen ist dabei identisch zur KDE Plasma Netbook Shell umgesetzt: über eine Schaltfläche aktiviert man einen "Present Windows" Effekt. Was mir bei diesem sehr gut gefällt ist die Möglichkeit Fenster direkt über eine Schaltfläche zu schließen (das findet man nun auch im 4.5 Featureplan, aber ich denke mir wird die Zeit nicht reichen). Was ich etwas schwach finde ist die Anordnung der Fenster: bei nur ein oder zwei Fenstern werden die meiner Meinung nach zu klein dargestellt.

Sehr schön umgesetzt sind auch modale Dialogfenster. Maemo hat hier eine spezielle Art von "Dim Inactive". Das Elternfenster wird nicht nur abgedunkelt sondern auch geblurrt wodurch man gar nicht erst in Versuchung kommt mit dem Elternfenster zu interagieren. Geschlossen wird ein Dialogfenster indem man neben den Bereich klickt, also in Fenstermanagertalk: indem es den Fokus verliert. Ich muss sagen, dass ich das sehr klever und intuitiv finde und in KWin auch sehr leicht umsetzen lassen würde.

Der Blur bei Dialogfenstern ist nicht so schön, wie z.B. der von KWin in 4.5. Für mich sieht es nach einem Mipmap-based blur aus – verständlich. Eine andere Mipmap anzusprechen ist die einfachste und sparsamste Variante. Gerade auch da der Vordergrund und nicht der Hintergrund geblurt wird und man den Inhalt ja nicht mehr erkennen soll. Diese Technik wird z.B. in KWin 4.3 beim Logout verwendet und auch teilweise im 4.4 Logout Blur. Auch solch eine Ergänzung wäre in KWin einfach umzusetzen und wäre vllt. sogar für den Desktopbereich interessant.

Andere typische Bereiche eines Fenstermanagers fehlen komplett oder sind als solche nicht erkennbar. So werden alle Fenster maximiert oder im Vollbildmodus dargestellt, womit der Bedarf an Fensterdekorationen überflüssig ist. Die Dialogfenster scheinen mir jedoch eine Dekoration zu haben, kann aber auch im GTK Stil umgesetzt zu sein. Die Schließen-Schaltfläche für das aktuelle Fenster befindet sich wie auch in der KDE Plasma Netbook Shell im Panel – ob es zum Fenstermanager oder zum Desktop gehört ist natürlich ohne in den Quellcode zu schauen nicht beantworten.

Focus-stealing-prevention scheint nicht zu existieren, zumindest ist mir in der Benutzung aufgefallen, dass der Fokus gestohlen wird. Ob das nun auf einem Handy erwünscht ist oder nicht, ist schwer zu sagen. Demands Attention finde ich sehr gelungen umgesetzt: die Schaltfläche zum Starten von Present Windows leuchtet auf und das Fenster wird dann hervorgehoben dargestellt, Benachrichtigungen werden über das Fenster gesetzt. Dies ist beim Empfangen von Emails oder IM Nachrichten sehr praktisch.

Was mich auch immer wieder freut zu sehen, ist dass alle nur mit Wasser kochen. Auch der Fenstermanager von Maemo hat mit dem Klassiker "Vorschaubilder minimierter Fenster" zu kämpfen. Nicht aktive Fenster werden in Present Windows nicht aktualisiert. Angesichts der kleinen Thumbnails ist das nun nicht weiter schlimm, zeigt mir aber, dass nicht aktive Fenster "minimiert" werden. Bisher habe ich aber noch nicht gesehen, dass die Thumbnails komplett verloren gehen, wie ich es von KWin kenne. Muss ich mal noch genauer beobachten.

Nun habe ich glaube ich lange genug über den Fenstermanager gerendet und wende mich mal anderen Bereichen zu. Als Browser kommt der als "Internet" gebrandete Mozilla Firefox zum Einsatz. Das Branding als Internet führt zu amüsanten Fehlermeldungen wenn er abstürzt und der Fenstermanager das Beenden anbietet 😉 Auch wenn ich eigentlich kein großer Fan von Firefox bin, finde ich die mobile Umsetzung bis auf wenige Ausnahmen sehr gelungen. Ein Problem liegt hauptsächlich in der fehlenden Fingerfertigkeit von Webseiten. Werden normale Dropdownlisten oder Eingabefelder in Maemo durch fingerfreundliche Varianten ersetzt, so ist das bei einem Browser einfach nicht möglich. Eingabefelder sind in der Regel nicht nativ (meines Wissens nach unterstützt nur KHTML native Widgets, Apple hat dieses Feature in Webkit leider rausgeschmissen). Was zum Beispiel sehr angenehm am Browser ist, ist die Möglichkeit wichtige Erweiterungen direkt über die Paketquellen zu installieren: welches Handy bietet denn AdBlock Plus im App-Browser an?

Das EMail Programm ist zum Lesen ausreichend, zum Mail senden jedoch eher ungeeignet, da ich bisher noch keine Möglichkeit gefunden habe die Absenderadresse zu verändern. Da ich z.B. für Mailinglisten andere Adressen verwende, ist das ein must-have feature. Leider hab ich auch noch keine Möglichkeit gefunden Ordner in der Übersicht auszublenden – bei mehr als 100 Mailordnern ist das auch nicht gerade nützlich. Mailthreading ist auch nicht unterstützt, was das Lesen von Mailinglisten erschwert.

Das Kartenprogramm hat sich leider als unbrauchbar herausgestellt. Die Karten sind zwar gut und sehr genau, jedoch fehlt eine geeignete Navigationsunterstützung. Das Programm kann Routen berechnen, die Position anzeigen aber nicht die Verfolgung und Ansagung von Abzweigungen. Somit leider nicht tauglich und ich muss wohl auf Marble2Go warten 😉 Da ich vorerst mich nicht motorisieren will, ist das jetzt kein großer Nachteil.

Das größte Highlight für einen jahrelangen Nutzer von Debian basierten Betriebssystemen ist natürlich die Paketverwaltung. Neben dem eigentlichen Paketmanager kommt Maemo mit standardmäßig installiertem XTerm worüber man ein schönet sudo apt-get update && sudo apt-get upgrade machen kann 😉 Root-Passwort kann man übrigens durch die Installation von openssh-server setzen. Wusste ich noch vom Maemo Vortrag auf der Akademy 2008 – war das erste was gesagt wurde: installiert ssh für das Root Passwort.

Nun ich freue mich schon darauf mit dem System zu entwickeln. KWin darauf zum Laufen zu bringen ist auf jeden Fall eine Herausforderung und wäre ein sehr schönes GSoC Projekt gewesen, leider hat sich jedoch kein Student dafür beworben. Durch meinen experimentellen OpenGL 3 branch, hab ich schon einiges an Vorarbeit geleistet (viele ifdefs um von OpenGL ES nicht unterstützten Code zu entfernen). Dies ist ein guter Startpunkt und muss nach und nach integriert werden. Ich denke mal, dass es mich den 4.6 Release Zyklus beschäftigen wird. Da ich mit Aurorae in 4.5 fast alle Ideen umgesetzt habe, ist das auch ganz praktisch wieder ein neues Aufgabenfeld zu haben 😉

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

Posted on

Announcing Aurorae Designer

I’m proud to announce the initial release of AuroraeDesigner, a small application to design Aurorae themes. At the current state of development it is possible to open an existing theme and get an interactive preview of the theme and change all configuration details. The changed configuration can be saved, but I’d recommend to backup the original file before starting to play with the designer 😉 Packages are available for openSUSE through the openSUSE build service. As it depends on 4.4, I was unable to build packages for other distributions.

Aurorae Designer
Aurorae Designer

For this designer I basically rewrote Aurorae upon the graphics view framework. As soon as it has reached feature parity (currently 90 %) it will become the base for the KWin decoration engine which will require a switch from KCommonDecoration to KDecoration, so I will be able to add features not possible with KCommonDecoration (e.g. decoration on the left side of the window).

If you are a designer of a theme: don’t worry. The new implementation is completely backward compatible, so your theme will look the same in 4.5 as it does in 4.4. Nevertheless there will be some new features added before 4.5 (e.g. window tabbing) so you should update your themes. In future releases of AuroraeDesigner I want to add a check method, so that you can easily verify that the theme contains all required elements.

As the screenshot illustrates the new Aurorae framework will also solve the question about buttons on left or on right: just show the elements on both sides 😀 But as it will not be possible to configure that in KWin I’d recommend to not use this "feature" 😉

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

Posted on

Die Welt der Fensterdekorationen

Eine der wichtigsten Aufgaben eines Fenstermanagers ist die Darstellung der Dekorationen. Die Dekoration erlaubt das Minimieren und Schließen des Fensters, zeigt wichtige Informationen wie Icon und Titel an und ist der „Container“ für ein eingerolltes (shade) Fenster. Je nachdem was der Fenstermanager unterstützt, kann die Fensterdeko auch Schalflächen für (vertikales/horizontales) Maximieren/Wiederherstellen, Fenster auf alle Desktops, Über/Unter anderen Fenstern halten anbieten. Jeder Fenstermanager, der NetWM unterstützt, sollte diese Aktionen bereitstellen.

Eigentlich müsste die Fensterdekoration nicht vom Fenstermanager bereitgestellt werden, das könnte auch die Anwendung machen, hat aber einige Nachteile. Die Aufgabe eines Fenstermanagers ist es Fenster zu managen. Er macht in der Regel nicht mehr und nicht weniger. Er ist ein absoluter Spezialist auf seinem Gebiet. Die Anwendung ist aber kein Spezialist im Bereich Fenstermanagement. Das bedeutet, dass Fehler, die in einem Fenstermanager schon längst behoben wurden, in einer Anwendung leicht reprdoduziert werden. Einfaches Beispiel: KWin hat vor dem Verschieben eines Fensters eine Verzögerung um Versehentliches Verschieben zu verhindern. Eine Anwendung würde das sehr leicht vergessen. So haben wir in KWin aktuell bei Quick Maximization ein „Problem“ weil Google Chrome einen Klick auf die Fensterdeko als Start von Verschieben interpretiert und somit wird das maximierte Fenster wiederhergestellt.

Die Fensterdekoration vom Fenstermanager bereitstellen zu lassen bietet uns auch andere Vorteile. So ist das Aussehen und Verhalten einheitlich. Hier auch mal ein Beispiel: In Ubuntu Lucid werden die Schaltflächen einheitlich links sein, Anwendungen, die selbst die Dekoration zeichnen, wie Google Chrome, haben es aber an ihrer eigenen Position – nämlich rechts. Das ist für den Nutzer sehr unschön. Möglichkeiten wie Window Tabbing wird natürlich auch erst möglich wenn der Fenstermanager das übernimmt und bereiten auch ernsthafte Probleme, wenn eine Anwendung meint eigene Dekorationen zu verwenden.

Ein ganz wichtiger Punkt ist auch die Barrierefreiheit. Der Fenstermanager kann global anbieten, dass alle Fensterdekorationen vergrößerte Elemente anbieten. KWin hat dafür z.B. global eine konfigurierbare Randgröße, unsere Standarddeko bietet zusätzlich noch konfigurierbare Größen der Schaltflächen an. Eine Idee, die ich für Aurorae übernehmen will. Würden Anwendungen die Fensterdekorationen selber zeichnen, müsste man entweder in jeder Anwendung oder für jedes Toolkit (GTK/Qt/$anderestoolkit) dies manuell einstellen und darauf hoffen, dass die Anwendung es unterstützt. Der Fenstermanager kann hier weiterhelfen auch wenn der Anwendungsentwickler nicht daran dachte.

Wir sehen also, dass Fensterdekorationen in den Aufgabenbereich des Fenstermanagers und nicht in die Anwendung gehören. Leider gibt es aktuell eine Tendenz aus der Browserwelt, dass Anwendungen selber zeichnen. Chrome hat damit angefangen und Firefox will es vielleicht auch übernehmen. Ich kann nur hoffen, dass die Erkenntniss einsetzt, dass es eine schlechte Idee ist. Die Idee kommt hauptsächlich aus der Windowswelt, wo viele Firmen Fensterdekos als Bestandteil ihres Brandings ansehen. Leider dient hier Microsoft als sehr schlechtes Vorbild. Hier ist Mac OS ein bedeutend schöneres Vorbild, da es die Fensterdeko erzwingt.

Aber in einem anderen Punkt kann Mac OS nicht als Vorbild dienen bei Fensterdekorationen: der Konfigurierbarkeit. Die Fenstermanager bieten einen unterschiedlichen Grad an Möglichkeiten die Fensterdekorationen anzupassen. Hier gehe ich jetzt selbst gar nicht weiter darauf ein, sondern verweise auf den Metacity Blog, der eine gute Zusammenfassung hat.

Leider hat sich die freie Softwaregemeinschaft noch nicht durchringen können einen gemeinsamen Standard für Fensterdekorationen zu schaffen. Hier köchelt jeder noch sein eigenes Süppchen und als Autor einer der Themeformate bin ich da selbst nicht ganz unschuldig 😉 Aber wieso kam ich auf die Idee ein neues Format zu erstellen? Ich hab mir natürlich die verschiedenen bestehenden Formate angeschaut. Am liebsten hätte ich die Metacity Themes unterstützt, jedoch ist das ein äußerst komplexes XML Themeformat und hat dabei nicht in meine Anforderungen gepasst (ich wollte eine Theme Engine, die es Designern ermöglicht leicht Themes zu erstellen). Das Human Theme von Ubuntu ist eine 33 KB große XML Datei mit 760 Zeilen und ist damit nur minimal kleiner als der komplette Quellcode der Aurorae Theme Engine.

Ein anderer guter Kandidat für eine einheitliche Theme Engine wäre Emerald gewesen. Emerald wurde aber faktisch von den Compiz Entwicklern aufgegeben und wird wohl nicht mehr Bestandteil der nächsten Compiz Version. Damit ist leider Emerald eigentlich schon ausgeschieden, es gab aber auch noch andere Punkte die dagegensprachen, wie die hohe Anzahl verschiedener Engines.

KWin selbst kann auch nicht mit einem Standard für Dekos ankommen. KWin hat eine C++ Programmierschnittstelle, was im Prinzip alles andere überbietet. Es gibt dem Entwickler der Fensterdekoration einen unglaublichen Gestaltungsspielraum. So konnten wir Window Tabbing zum Bestandteil der einzelnen Fensterdekorationen machen. Jedoch ist die Schnittstelle auch zum großen Teil KWin spezifisch und auf das Qt/KDE Programmiermodell zurechtgeschnitten und somit für z.B. Metacity nicht verwendbar. Compiz hat die Schnittstelle nachprogrammiert und es bereitet immer wieder Probleme, wenn wir Veränderungen vornehmen.

Eine Programmierschnittstelle ist auch nicht wirklich eine gute Lösung. Programmierer haben meistens keine Ahnung von Design und Designer keine Ahnung vom Programmieren. Nur wenige Designer halten es aus mit den Programmierern zusammen eine Deko zu erarbeiten. Daher ist der Anteil der Dekorationen für KWin auch eher gering. Würde ich versuchen eine Dekoration zu erstellen, würde ein katastrophales Ergebnis dabei herauskommen.

Die Lösung ist eine Theme Engine. Auf Basis der KWin Schnittstelle wurden mehrere Engines erstellt. Zum Beispiel QtCurve, deKorator und Aurorae. Keines der Formate eignet sich als einheitlicher Standard. Ich möchte es mal am Beispiel Aurorae aufzeigen, da ich mich da am Besten auskenne. Aurorae wurde geschrieben um die neuen Möglichkeiten in KDE SC 4.3 voll auszuschöpfen. Das Format ist daher sehr spezifisch zum Verhalten von KWin: Schatten sind Bestandteil der Dekoration. Im Unterschied zu z.B. Oxygen ist es nicht möglich und nicht erwünscht diese zu deaktivieren. Jeder andere Fenstermanager müsste also unser Verhalten nachimplementieren um Aurorae Themes korrekt anzuzeigen.

Die Metacity Entwickler entwickeln gerade auch ein neues Theme Format, welches auf CSS basiert. Ob Cowbell ein Kandidat für ein einheitliches Format wird, wage ich auch zu bezweifeln. Es wird zwar so entwickelt, dass andere Fenstermanager darauf aufbauen können und zumindest KWin könnte über die Schnittstelle eine Theme Engine erstellen, aber ich vermisse bisher noch einige Möglichkeiten und bin mir nicht sicher ob CSS eine angemessene Sprache zum Erstellen von Fensterdekos ist. Auch KWin spezifische Erweiterungen wie Window Tabs könnten schwer umsetzbar werden in einer Theme Engine, die für einen Fenstermanager entwickelt wurde, die keine Tabs unterstützt.

In diesem Blogpost wollte ich aufzeigen warum es die Aufgabe des Fenstermanagers ist Fensterdekos zu malen und warum es leider noch keinen einheitlichen Dekorationsstandard gibt und warum es nicht danach aussieht, dass es demnächst dazu kommen könnte, obwohl im letzten Jahr beide großen Fenstermanager (KWin und Metacity) angefangen haben ein neues Theme Format zu entwickeln.

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

Posted on

KWin in Tokamak IV

Unfortunately Tokamak is already over for me 🙁 I’m just sitting in the train back home, as my Thesis wants to get some finishing touch. I really enjoyed these three days. From the social point of view Tokamak is just like Akademy a great experience. And this Tokamak was really big. The openSUSE offices are a perfect place for the sprint as there is one room big enough for all of us and several small meeting rooms for the small breakout groups. Thanks again to Will for organizing everything.

On Saturday we mainly had presentations and today the breakout groups started. In the morning we had a small discussion about activities/context/whateveritscalledthesedays and came up with a small API for activitiy management. Looks like the KWin part will be easier to do as initially expected as we can use quite some of the virtual desktop code to (un)hide windows whenever the activity changes.

After lunch we started two discuss Plasma/KWin integration. I had a list of points for better integration and the funny thing is, that most of the issues the Plasma guys and girl mentioned were on this list. Quite good that we see the same points for improvements. The discussions were really productive and I think we found consensus in all discussed topics which will hopefully result in code written and a way better user experience. One of the discussed issues was an improved dashboard. Currently the dashboard is just a normal window, resulting in issues like it’s possible to alt+tab or start present windows. The idea is to tell KWin that the window is a dashboard and that we add special support for it including a nice fade-background effect replacing the currently black background rendered inside the dashboard.

Due to overlapping schedule I was unable to attend the mobile session. I will probably try to get KWin compiling on Maemo, which requires a port to OpenGL ES 1.1. I thought that N900 requires ES 2.0 which would require a shader scene and way more changes to KWin code base including huge #ifdef areas. OpenGL ES 1.1 on the other hand is just a stripped down version of OpenGL 1.5. So getting KWin compiling should be much easier. Of course there have to be some changes as some currently used calls are unsupported, but removing glBegin/glEnd and switching from rendering quads to triangles will probably improve overall KWin and as I have a "port" of KWin to OpenGL 3 in my local git repository I can (hopefully) just cherry-pick those changes.

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

Posted on

KDE Software Compilation 4.4 aka “Caikaku” veröffentlicht

Das Release Team hat gerade KDE SC 4.4 freigegeben und die Neuerungen des letzten halben Jahrs stehen nun allen Nutzern zur Verfügung. Ich selbst nutze die 4.4.0 seit Samstag Abend (durch die heutigen Änderungen in letzter Minute muss ich noch einmal neu bauen) und den 4.4 Entwicklungzweig schon seit einigen Wochen. Ich kann nur sagen, dass es ein richtig tolles Release ist und ich bin stolz, dass ich bei solch einer tollen Community mitarbeiten darf.

4.4 hat so viele umwerfende Neuerungen, dass ich hier gar nicht alles aufzählen kann. Daher schaut in die Release Note und den Visual Guide. Schaut euch die tollen Videos an, die ein paar der Neuerungen aufzeigen.

Meine persönlichen Highlights sind natürlich Aurorae und Alt+Tab. Aber auch andere Bereiche sind für mich eine echte Verbesserung, wie Blogilo, in dem ich gerade diesen Blogpost schreibe, oder die automatische Rechtschreibkorrektur in jeder auf Kate aufbauenden Anwendung – ein Segen, wenn man gerade eine Thesis schreibt. Aber auch Akonadi, der technischen Grundlage der Implementierung der Thesis, und nicht zu vergessen Nepomuk, mit dem ich endlich die gespeicherte Literatur durch Stichworte finden kann 😉

Und nun heißt es nach vorne schauen. Keine Zeit sich auf dem Zenit auszuruhen, sondern weiterarbeiten. In einem halben Jahr steht KDE SC 4.5 vor der Tür und wir wollen ja wieder ein tolles Release schaffen. Dafür steht in zwei Wochen Tokamak IV an – der nächste Plasma Entwickler Sprint auf den ich mich schon richtig freue (auch wenn ich eigentlich keine Zeit dafür habe). Wenn ich alleine auf meine TODO Liste schaue mit den Ideen für Integration zwischen KWin und Plasma, so wird 4.5 sicherlich auch wieder ein toller Nachfolger für 4.4 😀

Und nicht vergessen den Buzz zu 4.4 zu verfolgen 😉

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

Posted on

Neues KDE Fensterdekorationen Einrichtungsmodul

Es gibt wenige Bestandteile in KDE’s Desktop Shell, die sich seit langer Zeit nicht verändert haben. So erinnere ich mich, dass die erste KDE Version, die ich nutzte (das war ein 3.x mit x << 5), das gleiche Einrichtungsmodul für Fensterdekorationen verwendete wie aktuell in der KDE Software Compilation 4.4. Die Benutzeroberfläche besteht aus einem Auswahlfeld mit den Namen der verfügbaren Dekorationen, einem Konfigurationsabschnitt für die ausgewählte Dekoration und einer Vorschau. Dies führt zu so wunderbaren Oberflächen mit Unterfenstern in Unterfenstern – werft einfach mal einen Blick auf die Oxygen Konfiguration in 4.4.

Mit KDE SC 4.5 wird es ein neues Konfigurationsmodul geben, das man auch als Qt 4 Portierung bezeichnen könnte. Das Auswahlfeld wird durch eine Liste ersetzt welche eine Vorschau für jede Dekoration enthält. Der Konfigurationsabschnitt ist in ein Dialogfenster verschoben welches man durch eine Konfigurationsschaltfläche neben der Vorschau erreicht.

Neues Dekorationen KCM

Da ich der Meinung bin, dass man ehren sollte wem Ehre gebührt, wurde eine Informationsschaltfläche zum Anzeigen der Autorinformationen hinzugefügt. Hier müssen die Entwickler und Künstler noch die Informationen nachtragen – aktuell fehlen sie noch.

Aurorae Designs sind in der Liste wie „normale“ Dekorationen aufgeführt. Die Tatsache, dass Aurorae eine Theme Engine ist, ist eigentlich für den Nutzer ein unbedeutendes Implementierungsdetail und sollte verborgen sein. Und damit erhält KWin endlich Unterstützung für Get Hot New Stuff bei Fensterdekorationen (für die Nicht-KDE-Nutzer: GHNS bietet die Möglichkeit Themes und ähnliches direkt von kde-look.org herunterzuladen und zu installieren oder mit anderen Worten „die beste Erfindung für Moddingkinder seit Reis in Beuteln“) – und das ist einfach umwerfend. Ich hoffe, dass wir deKorator Themes in der gleichen Art und Weise integrieren können.

Leider habe ich das nicht mehr für KDE SC 4.4 fertigstellen können und wird erst in 4.5 integriert sein, also z.B. in Kubuntu 10.10 enthalten sein. (Ja Vorfreude auf neue Versionen ist immer wichtig)

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

Posted on

New Decoration control module

There are a few things in KDE’s desktop shell which have not changed for a very long time. For example I remember that the first KDE version I used (that was a 3.x with x << 5) had the same control module for window decorations as the one we will have in KDE SC 4.4. The interface displays a dropdown list with the names of the available decorations, a configuration panel for the selected decoration and a preview. This results in wonderful tabs inside tabs user interfaces – just look at the Oxygen configuration in 4.4.

With KDE SC 4.5 there will be a new interface which could be called the Qt 4 port of the decoration control module. The dropdown is replaced by a list view displaying previews of each decoration. The configuration panel is moved to a dialog which is accessible from a configure button next to the preview.

New decoration KCM

As I think it’s important to honor those who should be honored a button to access about data has been added. So if you have written a decoration please add your author information to the desktop file of your decoration.

Aurorae themes are included in the list just like "normal" decorations. The fact that Aurorae is a theme engine is an irrelevant implementation detail for the user and by that it should be hidden. And so KWin finally supports Get Hot New Stuff for decorations – that’s just awesome. I hope we will be able to integrate deKorator themes in the same way.

Unfortunately I was not able to finish this for 4.4.

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

Posted on

Wie man Entwicklern bei Bugs helfen kann

Gestern hab ich ja darüber geschrieben wie der Weg von Bug zu Fix ist. Nun hab ich einen wichtigen Punkt vergessen: Du, ja genau Du, kannst den Entwicklern dabei nämlich helfen. Du brauchst dazu nicht mal programmieren zu können.

Ich hatte ja erwähnt, dass etwa 40 % aller Bugs die für KWin gemeldet werden, bereits gemeldet sind. D.h. ich gehe hin suche den korrekten und markiere ihn als Duplicate. Ein Beispiel aus der Beta 1: KWin crashed after a Konqueror crash Uns ist kurz vor Beta 1 eine Regression in den Code gekommen und wie man an meinem Commit (erster Kommentar) sieht, war es eine Trivialität. Dieser Crash hat uns durch die ganze Beta 1 verfolgt und er hat entsprechend viele Duplicates. Aber alle Duplicate Markierungen sind von Entwicklern gesetzt und das muss eigentlich nicht sein. Das könnten die Nutzer übernehmen. In so einem Fall ist es wirklich einfach: der Backtrace ist immer gleich und DrKonqui hängt die möglichen Duplikate sogar an (einfach auf einen der Duplikate klicken).

Ein anderer Fall sind normale Bugs – auch hier kann uns jeder Nutzer eigentlich helfen. Wenn ein Bug aufgemacht wird, steht er zuerst auf "UNCONFIRMED". Hier könnte nun ein Nutzer eigentlich schauen ob das überhaupt stimmt. Ist die Beschreibung korrekt, lässt sich der Bug reproduzieren, etc. Also den Bug soweit aufbereiten, dass der Entwickler damit etwas anfangen kann. Typischer Fall eines Bugs: KWin is slow – please improve. Toll hilft nichts. Hier müsste nachgefragt werden, welche Hardware er benutzt, welche Anwendungen, ob Compositing aktiviert ist, etc. Für mich als Entwickler ist so eine allgemeine Beschreibung natürlich wertlos und in der Zeit die ich nachfrage, könnte ich Entwicklungsarbeit leisten.

Und selbst bei Crashes kann der Nutzer sehr einfach mithelfen. Viele Crashes werden ohne die Debug Pakete installiert zu haben gepostet. Da können wir dann gar nichts machen. Hier gibt es die Möglichkeit nachzufragen oder wenn ein Weg angegeben ist, wie man KWin crashen lassen kann, einfach reproduzieren und einen guten Crash anhängen.

Dennoch muss ich nachfragen um meine Bugliste sauber zu halten. KWin hat aktuell etwa 360 offene Bugs. Wenn ich die Liste durchgehe und manuell Duplicates suche dann bekomme ich idR in einer Stunde 10 Bugs weg. Nicht gerade viel. Viele Bugs haben einen Kommentar wie "Is this still an issue in KDE SC 4.3.3?" und danach ein halbes Jahr keine Antwort mehr. In so einem Fall kann der Bug zugemacht werden – scheint niemanden zu interessieren und war entweder nie ein Bug oder ist behoben. Auch das ist etwas was Nutzer übernehmen können.

Wenn ein Bug überprüft ist, dann kann er von "UNCONFIRMED" auf "NEW" geändert werden. Dies könnte von den Entwicklern nun genutzt werden um zuverlässig nach Bugs zu suchen. Die unnützen Bugs erscheinen gar nicht und der Entwickler kann sich einen Bug schnappen und ihn beheben ohne großen Verwaltungsaufwand. Ja das wäre die ideale Welt 🙂

Nun muss man natürlich nicht alleine als Nutzer plötzlich anfangen hier die Bugs zu durchforsten, sondern es gibt den KDE Bug Squad, der genau das macht. Regelmäßig veranstaltet die Gruppe Bug Days und aktuell gibt es auf forum.kde.org Bug Weeks. Der Bug Squad braucht übrigens immer Nachwuchs da viele Bug Jäger plötzlich abtrifften in die Entwicklung. So wurde die Überarbeitung von DrKonqui von einem Bug Squad Mitglied durchgeführt – Dario hatte einfach gesehen was nötig ist. Das Team beißt nicht und hilft immer weiter und Entwickler sind wirklich dankbar für die Arbeit. Also nichts wie los nach #kde-bugs.

Ach und natürlich braucht nicht nur KDE Nutzer, die bei Bugs helfen, sondern jedes Projekt.

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

Posted on

Vom Bug zum Fix

Angesichts der aktuellen Vorbereitung auf das Release der KDE Software Compilation in Version 4.4 hab ich gedacht ich beschreibe mal die Schritte, die ich gehen muss um einen gemeldeten Bug in KWin zu beheben. Denke das könnte ganz interessant sein, vor allem wenn man nicht so vertraut mit der Entwicklung ist 😉

Am Anfang steht der Bugreport. Im IRC channel #kwin gibt es einen kleinen bot, der neue Bug reports meldet. Da ich auch ein highlight auf das Wort "kwin" habe und dieses zufälligerweise in jeder Bug Meldung enthalten ist, erhalte ich eine schöne Benachrichtigung. Im Channel ist dann auch gleich die URL zum draufklicken enthalten. Wenn ich nicht am Rechner sitze, dann bekomme ich neue Bugs trotzdem mit: alle Bugzilla Mails werden auch an die kwin Mailingliste gesendet und zusätzlich hab ich in Akregator einen RSS feeds für neue Bugs (eigentlich überflüssig).

Ein Bug fällt in eine von drei Kategorien:

  • Wishlist
  • Bug
  • Crash

Wishlist ist ein Wunsch und so etwas wird idR erst einmal ignoriert. Gerade in der Zeit, in der man sich auf das Beheben von Bugs konzentriert, dürfen neue Wünsche eh nicht implementiert werden. Viele der Wünsche sind auch einfach nun ja Traumkonzert und lassen sich zwischen schwer bis gar nicht umsetzen.

Ein Bug ist ein Fehlvehalten der Anwendung. Im Falle von KWin beziehen sich die Meisten auf irgendwelche Probleme mit den Desktop Effekten. Viele der Meldungen sind sehr ungenau und nur unter bestimmten Fällen zu reproduzieren. Für einen Bug gilt eigentlich, dass er nicht besonders priorisiert ist. Außer es ist wirklich ein gravierender Bug.

Crash ist nun eine Sonderform eines Bugs: die Anwendung hat einen Nullpointer dereferenziert und ist abgestürzt. Bei KWin nicht so schlimm, da es sich automatisch neustartet, aber trotzdem unangenehm. Zum Glück sind mittlerweile die Anzahl der Crashes zurückgegangen, so dass im Normalfall keiner auftritt.

Bei allen drei Arten gilt, dass wir zuerst überprüfen müssen, ob der Bug schon existiert. In etwa 40 % der Fälle ist das so. Bei Crashreports ist das am Einfachsten: DrKonqui findet die automatisch und hängt die Nummer des Duplikats gleich dran. Leider reporten die User häufig trotzdem. In so einem Fall ist der Bug schnell weg: Nummer rein, und abschicken. Ansonsten wird die Suchmaschine im Hirn eingeschaltet und überlegt, ob man so einen Crash nicht schon mal gelesen hatte und wenn ja dann wird geschickt über die Suche von Bugzilla den passenden gefunden.

Natürlich ist es hilfreich den Bug reproduzieren zu können. Leider ist das nicht immer möglich, weil ganz bestimmte Bedingungen vorliegen müssen. Hatte aktuell so einen Fall, dass es nur crashed, wenn man Present Windows als Alt+Tab Effekt verwendet, während er aktiviert ist die Anzahl der Fenster auf 0 geht und man dann im richtigen Augenblick mit der Maus klickt. In dem Fall war dann zum Glück der Quellcode eindeutig und konnte sehr leicht auch ohne Reproduzierung behoben werden 😉

Die Crash Reports enthalten einen automatisch generierten Stacktrace, der Aufschluss darüber gibt an welcher Stelle im Code der Crash auftrat. Dabei werden die Code Zeilen sogar genannt und manchmal sogar die Werte übergebener Variablen. Für die Datenschutzfanatiker: nein daraus lassen sich keine privaten Daten rückverfolgen. Im Falle von KWin ist das maximal, dass man erfährt auf welchen Desktop der User gerade wechselte. Komplizierte Daten werden als Zeiger auf eine Datenstruktur übergeben – aus der Adresse kann man nichts rauslesen außer, dass sie vllt. 0 war. Ist der Bug gegen KDE SC 4.3 reportet worden so stimmen sehr häufig die Zeilennummern nicht mehr. Hier ist es dann hilfreich, wenn man den Crash selbst reproduzieren kann, weil man dann die passenden Zeilennummern erhält.

Mit der Zeilennummer bewaffnet, geht es dann in die Entwicklungsumgebung und man schaut sich den Quellcode an. In den meisten Fällen macht es schlicht und ergreifend "Aha" und der Crash ist offensichtlich. Nun die berechtigte Frage: Warum trat er dann auf? Nehmen wir das Beispiel von oben mit Present Windows: es wurde nicht daran gedacht, dass es vorkommen kann, dass man mit der Maus klickt, wenn kein Fenster da ist. Der Code ist ja gedacht ein Fenster auszuwählen. Ja eine falsche Annahme. Über den Stacktrace und den übergebenen Werten ist dann erkennbar welcher Zeiger auf 0 zeigt und man kann den Code anpassen, so dass dieser Fall entweder nicht mehr auftritt oder abgefangen wird.

Der nächste Schritt ist das neubauen von KWin (zum Glück direkt aus der IDE) und testen ob der Crash behoben ist. Wenn dem so ist, dann kann der veränderte Code in das Quellcodeverwaltungssystem eingespielt werden. KDE verwendet eigentlich SVN, was aber für mich eher unpraktisch ist, deswegen nutze ich selbst git und habe einen über git-svn verwalteten Checkout von kwin. Zuerst überprüfe ich die veränderten Code Zeilen mittels git diff – das zeigt mir in der Konsole an, was sich genau verändert hat. Eine wichtige Überprüfung um nicht irgendwelchen Müll durch das Testen (debug Ausgaben u.ä.) ausversehen einzuspielen. Auch eine gute Überprüfung ob der Coding Style eingehalten wurde. Der nächste Schritt ist die Änderung mittels git add und/oder git commit (-a) als lokalen Commit einzuspielen. Hierbei gibt man eine aussagekräftige Commit Message ein und trägt mittels BUG: NUMMER den Bug ein, welcher dadurch behoben wird. Nun muss der Code mittels git svn dcommit in das KDE SVN übertragen werden. Dabei wird dank dem BUG Schlüsselwort der zugehörige Bugreport automatisch geschlossen und ein Kommentar eingefügt.

Die Änderung wurde nun aber nur in trunk eingespielt – dem Hauptentwicklungszweig und das was in mehr als einem halben Jahr mal KDE SC 4.5 werden soll. Natürlich möchte ich den Bug auch in 4.4 behoben haben und dazu muss der Patch in den branch zurückportiert werden. Würde ich nicht git verwenden, wäre das richtig einfach, denn es gibt ein Skript dafür. Würde KDE git verwenden wäre es noch einfacher. Für mich bedeutet es manuelle Arbeit. Also mittels git show den letzten Commit in eine temporäre Datei speichern und in mein Verzeichnis wechseln, in dem der 4.4 Code rumliegt. Hier kann ich mit patch -i die Änderungen lokal einspielen. Bei 4.4 geht das noch ohne irgendwelches meckern, da es im Prinzip noch der identische Code ist. Nun müsste ich eigentlich die Änderung einspielen, hab aber mein Konsolen SVN Wissen dank git verlernt und nutze nun Dolphins SVN Integration. Dolphin öffnen, an die passende Stelle navigieren, über das Kontextmenü noch mal den Diff anzeigen lassen (lieber einmal zu viel kontrolliert, als einmal zu wenig) und die Datei committen. Als Commit Message wird die gleiche Meldung wie zuvor in git verwendet, jedoch mit dem Zusatz "Backport rev SVN-Nummer" und CCBUG anstatt BUG. Dadurch wird einfach nur eine Meldung an den Bug angehängt. Und da wir ja fleißig sind, machen wir das ganze für 4.3 auch noch mal sofern der Code passt.

So wie lange dauert so etwas? Beispiel von gestern abend: Um 20:54 Uhr hat mir ein User im IRC einen Crash gemeldet, er klang komisch und ich hab sofort ausprobiert und ihn reproduzieren können. Kdevelop war bereits mit der passenden Datei geöffnet (ist eigentlich immer offen) und ich konnte direkt an die Quellcodezeile springen. Um 21:06 konnte ich dem User melden, dass der Crash in trunk und branch behoben ist. Für den Backport in einen Branch brauche ich etwa 2 min – insgesamt alse 4 (IRC Log von CIA Bot). Zum Reproduzieren, Crashen und Testen, dass es wirklich behoben ist also gerade mal vier bis fünf Minuten. Ja der war wirklich einfach 😉 Heute saß ich an einem, bei dem ich nach etwa einer Stunde erst mal aufgehört habe, weil ich ihn nicht beheben konnte. Wird aber definitiv in 4.4 (notfalls über Würgaround) behoben sein.

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