Persönliches¶
 |
| Martin Gräßlin |
Erzähle erstmal etwas über dich! Wie würdest du dich beschreiben?
Ach muss das sein? Na gut, ich bin 25 Jahre alt, wohne in Mannheim und habe zuerst an der Berufsakademie Mannheim und anschließend an der Ruprecht-Karls-Universität Heidelberg Angewandte Informatik studiert. Im März hab ich mein Masterstudium abgeschlossen. Die Thesis behandelte die Implementierung neuer Ideen zur Spambekämpfung.
In meiner Freizeit arbeite ich als ehrenamtlicher KDE-Entwickler hauptsächlich am Fenstermanager KWin und bin auch Supporter hier im KDE-Forum. Hier bin ich als martingr bekannt; ein etwas älteres Kürzel aus der Zeit als mir Anonymität noch wichtiger war. Im KDE-Umkreis verwende ich das typische Kürzel erster Buchstabe des Vornamen + Nachname in ASCII. Bei mir also mgraesslin.
Das Beschreiben überlasse ich anderen. Ich beschreibe mich sehr ungern selbst und überlasse das lieber Leuten, die mich kennen.
Was machst du beruflich?
Ich arbeite beim Deutschen Krebsforschungszentrum in Heidelberg als Softwareentwickler. Bin also ein Wissenschaftlicher Mitarbeiter.
Rund um KDE¶
Nun kommen wir mal zu deiner „anderen” Arbeit. Du bist ja auch als KDE-Entwickler tätig. Woran hast du denn für das kommende Release von KDE SC 4.5 am meisten gearbeitet?
Für 4.5 konnte ich leider nicht so viel umsetzen wie für 4.4, da mein Studium in den letzten Zügen lag und ich somit keine Zeit für KDE hatte. Meine wenige Zeit habe ich in die Fensterdekorationen und insbesondere in meine Theme-Engine Aurorae investiert. Für den Nutzer am sichtbarsten ist wohl die Überarbeitung im Konfigurationsmodul für die Fensterdekorationen. Hier wird nun für jede Dekoration ein Vorschaubild angezeigt, wie man es beispielsweise von Metacity kennt. Aurorae wurde aus der Auswahlliste entfernt und jedes Theme ist nun direkt aufgeführt und, wenn ich alles richtig gemacht habe, nicht von nativen Dekorationen zu unterscheiden. In 4.5 ist es nun auch endlich möglich Fensterdekorationen mittels GetHotNewStuff (kurz GHNS) direkt von kde-look.org 🇬🇧 herunterzuladen. Hier nutzen wir auch den Trick über Aurorae. Für native Dekorationen besteht ja das gleiche Problem wie eh und je, dass sich diese über GHNS nicht verbreiten lassen.
Aurorae hab ich grundlegend überarbeitet und unterstützt nun viel mehr von Designern gewünschte Funktionen. Zusätzlich konnte als „last-minute commit” noch Window Tabbing in die Engine einbauen. Das Wichtigste aber ist, dass Aurorae nun auf einem Stand ist mit dem es sich gut erweitern lässt.
Jetzt hast du Aurorae recht häufig erwähnt? Was genau ist das denn?
Aurorae ist eine Theme Engine für Fensterdekorationen. Also so etwas ähnliches wie Emerald für Compiz. Das besondere an Aurorae ist, dass man für die Themes SVG-Dateien verwenden kann. Man kann also das Theme einfach in Inkscape erstellen. Intern baut die Engine auf das Themeing System des Plasma Desktops auf. Somit kann man recht einfach ein Plasma Theme in ein Aurorae Theme umwandeln. Dies ist gerade interessant, wenn man einen einheitlichen Workspace haben möchte.
 |
| Martins Desktop |
Und welches Theme verwendest du selbst?
Wie man auf dem Bild sehen kann, verwende ich Aurorae überhaupt nicht. Mir gefällt das Verschmelzen der Fensterdekoration mit dem Inhalt viel besser als eine losgelöste Dekoration und verschmelzen wird von Aurorae noch nicht unterstützt. In meinem Entwicklungsaccount nutzte ich zum Testen sehr gerne das „Chrome“-like Theme und „Radial“.
Das klingt ja interessant. Nur werden wir Ubuntu-Nutzer wohl kaum in Genuss davon kommen, oder?
Es gibt ja immer die lohnende Möglichkeit eines sudo aptitude install kubuntu-desktop. 😉 Aber es dürfte bald auch bessere Unterstützung für Aurorae geben. Ich arbeite mit den Compiz-Entwicklern daranl, Aurorae als weiteren Decorator zu integrieren. Auf einer experimentellen Basis funktioniert das bereits. Ich hoffe, dass wir das für Ubuntu 10.10 zum Laufen bekommen, denn es würde für Compiz durch den Wegfall von Emerald eine wichtige Lücke schließen. Natürlich lassen sich KDE-Abhängigkeiten nicht ganz vermeiden, aber man benötigt nur die KDE-Bibliotheken, welche ja auch für Amarok (auch unter GNOME einfach unverzichtbar) benötigt werden.
Inwiefern hattest du bei dem Design von Aurorae mitgewirkt?
Aurorae ist ja „mein Baby“, also ich hab das Softwaredesign komplett selbst bestimmt. Jedoch hab ich mich vom Design her sehr an unseren bestehenden APIs orientiert.
Welche Faktoren (Arbeitsfluss, Design…) haben das Konzept von Aurorae beeinflusst?
Aurorae war ursprünglich nur ein Versuch Plasma Styling für Fensterdekorationen zu ermöglichen. Meine Erwartung war eigentlich, dass es so langsam ist, dass es niemand benutzen will. Mir ging es daher eigentlich nur darum, unsere Fensterdekorationen-API kennen zu lernen und mich etwas intensiver mit Plasmas Theming zu beschäftigen; zwei Bereiche die ich bis dahin nicht angefasst hatte. Zusätzlich wollte ich die neuen Möglichkeiten von KWin in KDE SC 4.3 ausnutzen. Seit 4.3 ermöglicht KWin transparente Fensterdekorationen und zum Release gab es keine Deko, die es voll ausnutzte. Oxygen nutzt es nur für die Schatten, die Dekoration selbst ist voll opaque. Ich wollte also eigentlich ein Demonstrationsobjekt haben.
Mittlerweile hab ich natürlich andere Ziele mit Aurorae, die das Design beeinflussen. Ich habe verschiedene Ideen, um Fensterdekorationen allgemein zu verbessern und sehe Aurorae da als Testplattform an, um erfolgreiche Konzepte in unsere API zu übernehmen. Generell orientiere ich mich sehr stark an bestehenden Dekorationen und mein inoffizielles Ziel ist, dass Aurorae Oxygen mit Standardeinstellungen korrekt rendern kann. Davon ist sie noch weit entfernt, was das generelle Problem von Theme-Engines ist. Es fehlt einfach an Möglichkeiten etwas umzusetzen, was in der Engine nicht vorgesehen ist.
Was war das Wichtigste bei der Designgestaltung?
Aurorae richtet sich eigentlich an Designer. Mir geht es darum den Designern ein Werkzeug in die Hand zu geben, mit dem sie Dekorationen so einfach erstellen können wie ein Plasma Theme. Die Möglichkeiten für den Nutzer das Aussehen eines Themes zu verändern sind daher eingeschränkt. Der Nutzer kann die Anordnung der Schaltflächen verändern (das Theme kann einen Standard vorschlagen) und der Nutzer kann die Größe der Schaltflächen und der Ränder beeinflussen. Diese zwei Optionen sind für Barrierefreiheit gedacht.
Stand schon von Anfang an das jetzige Konzept fest oder wurden während der Entwicklung an Aurorae einige Konzepte über Bord geworfen?
Nein, wie ich schon erwähnte, hab ich für 4.5 das Design grundlegend geändert. Mir ist einfach klar geworden, dass das Design für die neueren Anwendungsfälle nicht geeignet ist. Ich habe daher auf eine andere interne KWin API umgestellt und die Engine auf Qts GraphicsView Framework portiert. Dieses Framework wird zum Beispiel vom Plasma Desktop verwendet. Erst durch diese Umstellungen sind Neuerungen wie der Aurorae Designer oder der Compiz Port denkbar geworden.
Und an welchen Stellen wurde das alte Konzept mit dem neuen gebrochen. Warum wird weiterhin die alte Reihenfolge der drei „Knöpfe“ Minimieren, Maximieren und Schließen angewendet?
In den Standardeinstellungen verhält sich Aurorae wie jede andere Dekoration auch. Für alle Standardwerte werden die von KWin direkt weitergereicht. Die Themes haben nun in 4.5 die Möglichkeit mehr vom Standard abzuweichen. So kann man nun die Titelleiste an jeder Seite des Fensters platzieren. Gerade für 16:10 Bildschirme eine interessante Option.
Ich habe aber noch einige Ideen, die ich für 4.6 umsetzen möchte. Eine Idee ist die Fensterdekoration für maximierte Fenster auszublenden und als Overlay-Window anzuzeigen, wenn man mit der Maus an den oberen Bildschirmrand fährt. Also ähnlich zu dem Autohiding von Plasma Panels. Auch spiele ich mit dem Gedanken eine Schaltfläche für Wechsel in den Vollbildmodus einzuführen.
Die von Canonical für Ubuntu 10.10 angekündigten „Windicators” habe ich nicht vor zu unterstützen. Ich halte die Idee für nicht sehr ausgereift bis schlecht und möchte natürlich erst mal sehen wie sich das entwickelt. Aktuell unterstützt kaum ein Aurorae Theme alle verfügbaren Schaltflächen und ich erwarte nicht, dass Designer plötzlich anfangen Schaltflächen für Windicators zu erstellen. Einen Fallback für nicht unterstützte Schaltflächen habe ich im Design von Aurorae immer abgelehnt und habe auch nicht vor, dies zu ändern. Ein Fallback würde die visuelle Konsistenz eines Themes komplett zerstören.
Für die Anordnung der Schaltflächen folgt Aurorae dem KWin Standard. Jedoch kann jedes Theme eine andere Vorgabe machen.
Über Canonical¶
 |
| Martins Schreibtisch |
Wie stehst du zu Canonicals Entscheidung die Fensterknöpfe in Ubuntu nach links zu verschieben?
Nun ich hätte es nicht ohne guten Grund gemacht. Und ein guter Grund wäre für mich nur, dass das KDE Usability Team eine Benutzbarkeitsstudie zu dem Thema macht und die Ergebnisse dann von uns umgesetzt werden. Bei Canonical ist mir von keiner solchen Studie bekannt. Zumindest wurde nichts kommuniziert.
Das Problem mit der Veränderung der Anordnung ist, dass es eine typische Bike-Shedding-Diskussion ist. Der Mehrwert der Änderung ist eher gering, hat aber Auswirkungen auf alle Anwender. In der Regel ist es meiner Meinung nach besser die Finger davon zu lassen.
Persönlich würde ich das Verschieben nach links niemals in Betracht ziehen, da es Apple zu stark kopiert. Wenn ich eines in meiner Zeit als Open-Source-Entwickler gelernt habe, dann dass man nicht Apple kopieren darf, außer man macht es viel besser. Dass beim Verschieben nach Links jeder an Mac OS denkt ist ja nicht verwunderlich. Und den Vergleich mit Apple sollte man einfach meiden, da kann man nicht gewinnen, selbst wenn man besser ist. Abgesehen davon finde ich das Verschieben nach links schlecht, weil außer bei Mac die Schaltflächen immer rechts sind. Für Umsteiger, sei es von Microsoft Windows oder KDE, wird die Umstiegshürde dadurch ohne Mehrwert erhöht. Auch denke ich an die arbeitende Bevölkerung, die nur privat Linux einsetzen kann. Diesen macht man es unnötig schwer. Ich selbst merke es tagtäglich, wie ich falsch klicke – und ich muss mich „nur“ von KDE SC 4.3 auf 4.4 umstellen.
Warum investierst du überhaupt noch Arbeit in eine Fensterdekoration? In Ubuntu 10.10 werden Fensterdekorationen doch sowieso abgeschafft.
Die Änderung betrifft ja erstmal nur Ubuntu. In der KDE Community hat niemand vor, Client-Side-Windowdecorations (CSD) einzuführen. Und ich hoffe – nein ich erwarte –, dass auch die Ubuntu-Entwickler noch erkennen, dass dies ein falscher Schritt wäre.
Erkläre kurz was CSDs sind!
Vereinfacht gesagt geht es darum, dass nicht mehr der Fenstermanager sondern die Anwendung selbst „diese drei Knöpfe“ zeichnet. Leider ist die Anwendung halt kein Fenstermanager und eine Fensterdekoration ist bedeutend mehr als „diese drei Knöpfe“.
Aus den Antworten lässt sich ja schon erahnen, dass du nicht gerade ein Freund dieser anstehenden Änderung bist. Kannst du uns erklären, warum du gegen diese Neuerung bist?
Nun in der Kürze des Interviews sicherlich nicht. Ich versuche es aber trotzdem mal. Wenn jemand bei uns in den IRC-Channel kommt und eine Idee hat und etwas implementieren will, dann bekommt er von mir immer als erstes die Rückfrage „Warum?“. Diese Frage stelle ich mir bei CSD auch. Warum will man ein seit mehr als 20 Jahren funktionierendes Konzept durch etwas Neues (schlechteres?) ersetzen? Und hier sehe ich leider keine Antworten. Im GNOME Wiki finden sich sechs Gründe für CSD. Alle habe ich widerlegen können, vieles davon haben wir in KWin sogar implementiert.
CSD führen auf jeden Fall zu einer unglaublichen Inkonsistenz. CSD werden nun im GTK-Stil implementiert. Das heißt, alle GTK-Anwendungen werden diesen verwenden. Qt und somit KDE-Anwendungen haben kein CSD und da Qt 4.7 schon im Feature Freeze ist, kann man mit Sicherheit sagen, dass Qt in 10.10 das nicht unterstützen wird. Also wird eine Qt Anwendung andere Dekorationen haben als eine GTK-Anwendung. Die Konsistenz wird somit noch schlechter als sie aktuell ist. Von den ganzen Anwendungen, welche ein eigenes oder ausgefallenes Toolkit haben, möchte ich gar nicht erst sprechen. Ich würde diese Anwendungen nicht patchen wollen; und im Falle von proprietären Anwendungen ist es ja eh unmöglich.
Aber Konsistenz ist nur eins der zahlreichen Probleme. Dekorationen machen halt viel mehr. Zum Beispiel erfordert die Spezifikation für Fenstermanager, dass die Funktion „Fenster einrollen“ nur mit einer Dekoration geht. Ohne Dekoration kein Einrollen. Oder wenn eine Anwendung in einer Endlosschleife gefangen ist, konnte der Fenstermanager erkennen, dass sie nicht reagiert, wenn der Schließen-Knopf gedrückt wurde und sie zwangsweise beenden. Mit CSD ist der Schließenknopf Bestandteil der hängenden Anwendung. Man kann sie also nicht mehr einfach beenden.
Die Liste der Funktionen, die verloren gehen ist riesig. Meine Angst ist vor allem, dass die GTK-Entwickler sich an Metacity orientieren und all der Zusatz von KWin dann verloren geht. Vor allem fürchte ich, dass Anwendungen ihren eigenen Stil erzwingen werden. Dann hat man bei einer Anwendung die Schaltflächen links, bei der anderen rechts und die dritte meint, dass maximieren eine dumme Idee ist. Ein Fenstermanager kann sicherstellen, dass Anwendungen sich immer gleich verhalten.
Natürlich gibt es auch noch grundlegende technische Probleme, wie zum Beispiel dass ein Fenstermanager einfach einer Anwendung Dekorationen verpassen kann, ob sie es will oder nicht. Denn dafür ist der Fenstermanager ja auch da.
Was tust du, um deine Meinung zu vertreten? Hast du die Entwickler von Canonical schon mal auf die Gefahren hingewiesen?
Ich habe mehrere Blogposts zu dem Thema verfasst, die auf PlanetKDE 🇬🇧 veröffentlicht wurden. Einen der Artikel habe ich direkt an den GTK-Entwickler als offenen Brief verfasst und ihm auch per E-Mail eine Kopie zugesandt.
In den Beiträgen habe ich die Gefahren sehr ausführlich herausgearbeitet und aufgezeigt, warum die angeblichen Argumente für CSD nicht stimmen.
Wie stehen die anderen KDEler dazu?
Ich habe eigentlich nur volle Zustimmung für meine Beiträge erhalten. Dank der Reaktionen bin ich mir nun sicher, dass bei uns niemand CSD will. Glücklicherweise habe ich auch Unterstützung von Entwicklern anderen Fenstermanagern erhalten, zum Beispiel von unseren Freunden von Compiz und Enlightment.
Leider ist von Seiten der GNOME/GTK-Entwickler nicht viel zurückgekommen. Auf meine Bitte mir Gründe für CSD zu nennen oder wo es bei bestehenden Dekorationen fehlt, konnte bisher nicht eingegangen werden. Es erscheint mir eher, dass die Argumente nicht verstanden werden. So erwähne ich sehr gerne Chromium als Beispiel, insbesondere die falsche Anordnung der Schaltflächen in Lucid. Hier wird nun dagegen gehalten, dass Chromium im Entwicklungszweig sich nun angepasst hat. Ich denke, es dürfte jedem klar sein was es bedeutet, wenn jede Anwendung sich an die neuesten Ideen der richtigen Anordnung einer Distribution anpassen muss. Natürlich ist so was auch nicht generell möglich. In meinen Beiträgen habe ich zum Beispiel ausführlich erklärt, warum es im Falle von KWin für eine externe Anwendung unmöglich ist die Anordnung zu ermitteln.
Ich wünsche mir auch für alle Nutzer von Ubuntu, dass diese Verschlimmbesserung nicht Einzug erhält.
Der Weg in die Community¶
Wie bist du dazu gekommen dich bei KDE einzubringen?
Ich war eigentlich schon von Anfang meiner Linuxnutzung begeisterter KDE-Nutzer und wollte schon seit langem etwas zurückgeben. Mir hatte zum Programmieren einfach die Zeit gefehlt und durch die Neuentwicklung im Zuge von KDE 4 auch nicht die Gelegenheit gesehen einsteigen zu können. Um den Zeitpunkt KDE 4.0 herum, kamen einige Ereignisse zusammen, die es mir endlich ermöglichten. Zum einen war mit 4.0 endlich eine stabile Basis zum Entwickeln da, ich hatte erkannt was für ein unglaubliches Potential in der Plattform liegt und ich hatte durch den Umstieg ins Masterstudium mehr freie Zeit. Ich hatte an der Universität gerade die Vorlesung Computergrafik gehört bei der ein OpenGL Kurs dabei war und hab die neuen KWin Effekte gesehen und mir gedacht: „Komm probier doch einfach mal!“
Und warum engagierst du dich noch zusätzlich auf ubuntuusers.de?
In das Team bin ich etwa zeitgleich zu meinem Beginn mit der KDE-Entwicklung gekommen. Auch durch die zusätzliche Freizeit, hatte ich ein bisschen im Wiki gearbeitet und irgendwie fanden die Mods meine Arbeit ganz gut. Mittlerweile bin ich nur noch KDE-Supporter. Dies ist mir sehr wichtig, weil ich dadurch Kontakt zu Anwendern habe. Nicht jeder Anwender meldet Bugs und in einem Forum sieht man sehr gut, wo es noch richtig hakt. Wo die Benutzbarkeit zum Wünschen übrig lässt. Es gibt einige Bug-Fixes und Verbesserungen die einem Thread entstammen. Aus gleichem Grund überwache ich auch ein bisschen das KWin Forum auf forum.kde.org 🇬🇧 .
Du nutzt dann doch sicherlich Kubuntu?
Nicht mehr. Seit etwas mehr als einem halben Jahr nutze ich Debian Testing und auf Arbeit wird OpenSUSE eingesetzt.
Arbeitest du auch sonst noch an anderen Projekten?
Ab und zu schreibe ich einen Artikel für das freiesMagazin (Ausgabe Mai 2010 enthält übrigens einen Artikel zu Fensterdekorationen). Ansonsten ist mit KDE natürlich die Zeit gut ausgefüllt und RL (Real Life) gibt's ja auch noch. 😉
Hast du ein Ziel, welches du mit Deinem Communityaktivitäten verknüpfst?
Ja natürlich! Ich möchte, dass jedem Nutzer die bestmögliche Userexperience zur Verfügung steht. Computer sollen uns helfen Arbeiten einfach zu erledigen und wir sollen uns nicht mit der Benutzung beschäftigen. Das erklärt auch warum mir das CSD-Thema so wichtig ist: Es ist eine Änderung, die meinem Ziel entgegengesetzt ist.
Wie viel Zeit verbringst du mit deinen „Hobbys“?
Gilt die Antwort „zu viel“? Ich kann es nicht wirklich beantworten, da ich es einfach nicht weiß.
Liegt dir sonst noch was auf dem Herzen?
Ach wenn ihr schon fragt: Wir können immer Leute gebrauchen, die uns bei der Verwaltung der Bugs helfen. Dafür braucht es keine Programmierkenntnisse. Das kann jeder. Einfach schauen ob die gemeldeten Bugs reproduzierbar sind, ob er vielleicht schon gemeldet ist, ob es nicht ein Bug in einer anderen Komponente ist. Es ist einfach ärgerlich, wenn ich als Entwickler meine Zeit zur Bugverwaltung opfere, die Zeit könnte ich sinnvoller einsetzen und davon hätten alle Nutzer etwas. Wer Interesse hat, kann sich hier weiter informieren: techbase.kde.org/Contribute/Bugsquad 🇬🇧
KDE bedeutet für Dich…
Freundschaft. KDE ist eine unglaubliche Community. Wir sind wie eine riesengroße Familie und jeder ist willkommen. Ich freue mich jedes mal, wenn ich wieder auf einen Sprint fahren kann und die anderen Entwickler treffen kann.
