Motor Tuning

Mittlerweile hat das KDE Release Team begonnen die Quellcode-Pakete für die KDE Applications, KDE Workspaces and KDE Platform in Version 4.9 vorzubereiten, was für mich mal wieder ein guter Zeitpunkt ist zurückzuschauen auf das letzte halbe Entwicklungsjahr im KDE Plasma Fenstermanager und Compositor KWin.

Für den Nutzer wird es in KWin 4.9 nicht viel Neues zu sehen geben. An einigen Stellen haben wir die Benutzbarkeit etwas erhöht, so zum Beispield das Konfigurationsmodul für Fensterwechseln komplett überarbeitet und das Konfigurationsmodul für Fensterdekorationen ist nun interaktiver geworden.

Dies war aber auch nur möglich durch einige Arbeiten unter der Haube. Die Fensterdekorationsengine Aurorae wurde mittels QtQuick neugeschrieben, ist dadurch bedeutend wartbarer und performanter geworden und ist nun zumindest auf meinen Systemen performanter als unsere Standarddekoration Oxygen. Als Nebeneffekt kann der Quellcode auch in dem Konfigurationsmodul verwendet werden, was die nun existierende Interaktion erst ermöglicht.

Aber nicht nur der Motor der Aurorae Themes wurde getuned, nein der ganze Fenstermanager musste an sich Anpassungen ergehen lassen. Der Startvorgang ist deutlich beschleunigt, vieles wird nun parallel abgearbeitet und generell wird nicht mehr so viel gewartet um zum Beispiel eine Konfigurationsdatei einzulesen. Das dürfte je nach Hardware den Startvorgang des KDE Plasma Desktops um ein paar hundert Millisekunden beschleunigen.

Durch die generellen Umbaumassnahmen am Motor waren wir auch in der Lage einige richtig alten Bugs zu beheben. So ist der zweite Bug Report, den ich für KWin als Entwickler aufgemacht habe, nun endlich behoben: Fenster werden nach dem Schließen nicht mehr über andere Fenster gesetzt sondern behalten ihre Position. Was eigentlich nur nach einem Schönheitsfehler klingt, ist durchaus auch relevant für die Sicherheit. Durch diesen Bug wurden Benachrichtigungen für ein paar Millisekunden über der Bildschirmsperre angezeigt. Leider ist die Änderung doch sehr tiefgreifend und bringt den Motor noch etwas zum “stottern”, daher können wir die Änderung nicht in 4.8 einarbeiten. Bis zur Veröffentlichung von 4.9 bekommen wir das Stottern aber noch in den Griff. Gerade eben hatte ich einen Crash dadurch, fünf Minuten später war der Review Request mit dem Fix bereits erstellt.

Auch in anderen Bereichen haben wir daran gearbeitet, dass der Motor einfach runder läuft. So wurden die “Fenstertabs”, also die Funktionalität mehrere Fenster in einer Fensterdekoration zu haben, komplett neu geschrieben um die Stabilität zu erhöhen. Dies war ursprünglich einmal ein Google Summer of Code Projekt gewesen und wurde leider nach Abschluss des Projekts vom Studenten nicht weitergepflegt.

Auch ein anderes Google Summer of Code Projekt wurde in diesem Release Zyklus neu geschrieben und ausgebaut: Scripting. In 4.9 können nun Skripte entweder als JavaScript oder als QtQuick geschrieben werden und wir machen davon durchaus Gebrauch. Die Anzeige, wenn der Desktop gewechselt wird, wurde durch ein QtQuick Skript ersetzt und einige Anpassungen zum Deaktivieren der Multi-Monitor-Unterstützung haben wir in Skripte ausgelagert.

Skripte können nun auch bedeutend einfacher erstellt werden, nämlich über die Window Skripting Console, zu starten über KRunner (Alt+F2) und dann “wm console”. Der JavaScript Code wird direkt im Fenstermanager ausgeführt und ermöglicht somit ein sehr einfaches Ausprobieren der Skripte.

Ein zusätzliches Highlight ist, dass man nun Desktop Effekte in JavaScript implementieren kann. Ein paar Effekte haben wir damit auch bereits ersetzt und einige hundert Zeilen C++ Code durch ein paar JavaScript Zeilen ausgetauscht. Interessant ist, dass dies keinerlei Auswirkung auf die Performance hat, denn zum eigentlichen Zeichnen und Animieren wird weiterhin ein ausgereiftes C++ Backend verwendet. Ausschließlich Code zum Starten der Animation ist in JavaScript geschrieben.

Zusammengefasst denke ich, dass unsere Nutzer sehr zufrieden mit diesem Release sein werden und uns nachsehen werden, dass es keine neuen Spielereien gibt. Dafür haben wir aber die Grundlagen gelegt, dass unsere Nutzer selbst mittels JavaScript und QtQuick neue Spielereien nachreichen können. Mein Vortrag auf der diesjährigen Akademy wird sich um genau dieses Thema drehen.

Wer die Entwicklungen der KDE Community finanziell unterstützen will, kann zum Beispiel bei Join the Game teilnehmen. Für die KDE Community ist solch eine Unterstützung unglaublich wichtig, da wir Server zu bezahlen haben und wir das Geld einsetzen können um Entwickler zu den Sprints zu fliegen. Gerade die Entwicklersprints sind unglaublich hilfreich für die Entwicklung der Software, da hier die Entwickler die Möglichkeit haben mal direkt miteinander zu sprechen als immer nur über E-Mail oder IRC.