From the land of wobbly windows
Heute war das letzte große Ereignis meines Studiums: Abschlussvortrag mit anschließender mündlicher Prüfung. Nun warte ich nur noch auf die Note für die Masterarbeit 🙂 Zumindest gibt es nur noch zwei Möglichkeiten für die Endnote, wer wissen will, welche darf gerne persönlich nachfragen 😉
Nun ist also das schöne Studentenleben vorbei und nach Ostern beginnt der Ernst des Lebens. Bin ja mal gespannt
=-=-=-=-=
Powered by Blogilo
Sowohl Heise als auch pro-Linux berichten heute über einen Ressourcen Test verschiedener Desktopumgebungen auf Phoronix. Während pro-Linux Teile des Tests anzweifelt, stellt Heise den Test überhaupt nicht in Frage und fragt nur ob KDE ein Ressourcenfresser ist. Diese Frage kann der Test nicht beantworten.
Bevor man mich hier gleich mit Kommentaren bombardiert: ja ich bin davon überzeugt, dass der KDE Workspace mehr Speicher verbraucht als andere Desktopumgebungen. Ich denke dass das auch OK ist und den Anforderungen gerecht wird.
Lese ich den Test so stelle ich mir einige Fragen:
Jede Frage einzeln betrachtet, stellt die Testergebnisse komplett in Frage. Aber gerade die letzte Frage sollte doch einiges aufzeigen. Liest man den Test so hat man ein Ubuntu verwendet und kubuntu-desktop nachinstalliert. Nun ist Ubuntu + kubuntu-desktop nicht das gleiche wie Kubuntu. In dieser Situation wird zuerst GDM geladen (und somit große Teile von GNOME) und anschließend der KDE Desktop. Hier stellt sich nun die Frage, ob GDM nach dem Anmelden beendet wird. Wenn nicht, dann sind die Messergebnisse komplett verfälscht. Kennt man sich ein bißchen mit dem Speichermanagement aus, so weiß man, dass der Kernel selbst wenn GDM beendet wird, den Speicher nicht unbedingt freigibt. Leerer Speicher ist unnützer Speicher. Wie auch immer das mit GDM aussieht, ist es ziemlich egal, denn die Test-Suite scheint in GTK+ geschrieben zu sein. Man sieht also: traue keiner Statistik, die du nicht selbst gefälscht hast.
Noch amüsanter ist die Betrachtung des Stromverbrauchs. Der Artikel erwähnt nicht, dass mit einem externen Tool getestet wird, sondern es klingt eher danach, dass mit Software gemessen wird. Auch wird nicht erwähnt ob das Netzkabel angeschlossen ist oder nicht. Hier sei erwähnt, dass KDE zum Beispiel bei Batterienutzung die Indizierung der Dateien ausschaltet. Was natürlich gleich zum nächsten Punkt führt: Nepomuk. KDE liefert eine komplette Desktopsuche mit, welche bei mir nach dem Start anspringt. Kein Wunder also, dass nach dem Start der Ressourcenverbrauch höher ist als bei anderen Systemen.
Auch ist die Wahl der Distribution sehr merkwürdig. Die Ubuntu GNOME Variante als GNOME zu bezeichnen, grenzt schon an Frechheit. Meines Wissens nach verwendet Ubuntu z.B. Compiz anstatt Metacity, Notify-OSD anstatt GNOME Benachrichtigungen, Ubuntu GTK Theme anstatt Clearlooks. Ähnlich schlimm ist es die Ubuntu+KDE Variante als KDE zu bezeichnen. Von Kubuntu ist ja bekannt, dass die Python Hintergrundprogramme ärger bereiten. Diese sind in Kubuntu zum Glück am Abnehmen, aber das System ist ja ein Ubuntu+KDE, also müsste man davon ausgehen, dass die von Ubuntu im Autostart hängenden Anwendungen (z.B. Apport) auch in KDE ihr Unwesen treiben und Speicher verschwenden.
Ich könnte jetzt eigentlich hier noch viel mehr aufzählen, jedoch denke ich, dass es reicht um zu zeigen, dass der Test nicht seriös ist. Von Phoronix bin ich hier eigentlich nicht enttäuscht – dass die Tests nichts aussagen ist eigentlich bekannt. Wovon ich enttäuscht bin, ist die schlechte Recherche unserer sogenannten Redakteure bei Heise. Selbst wenn sie den Test nicht selbst durchgeführt haben, hätten die systematischen Testfehler auffallen müssen und ein kurzer Blick in das Phoronix Forum hätte gezeigt, dass viele begründet die Testergebnisse anzweifeln. Ich möchte hier einfach nur mal an Ziffer 2 des Pressekodex erinnern: Sorgfalt
Recherche ist unverzichtbares Instrument journalistischer Sorgfalt. Zur Veröffentlichung bestimmter Informationen in Wort, Bild und Grafik sind mit der nach den Umständen gebotenen Sorgfalt auf ihren Wahrheitsgehalt zu prüfen und wahrheitsgetreu wiederzugeben. Ihr Sinn darf durch Bearbeitung, Überschrift oder Bildbeschriftung weder entstellt noch verfälscht werden. Unbestätigte Meldungen, Gerüchte und Vermutungen sind als solche erkennbar zu machen.
=-=-=-=-=
Powered by Blogilo
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
[Update]Es hat sich herausgestellt, dass die Screenshots auf denen meine Kritik aufbaute, nicht die endgültige Fassung darstellte. Die Kritik in diesem Post ist damit überholt. Dennoch vielleicht ein lesenswerter Post zur Anordnung von Fensterdekorationsschaltflächen.[/Update]
Gestern wurde das neue Design für Ubuntu Lucid Lynx angekündigt. Ich hab einen Blick darauf geworfen und sofort die Hände über dem Kopf zusammengeschlagen, weil es einen schwerwiegenden Fehler enthält. Onli hat den eigentlich schon gut auf den Punkt gebracht.
Jedoch schreibt Onli, dass er die Kritik zurückzieht, wenn sich herausstellen sollte, dass Canonical Benutzertests gemacht hat. Das würde ich nicht, da ich leider aus Erfahrung sprechen kann. Die Tatsache, dass die Kontrollen von rechts nach links verschoben wurden, sehe ich gar nicht als so schwerwiegend an. In KWin erlauben wir den Dekorationen die Positionen selbst zu bestimmen und sehen es als Bestandteil des Designs an und spiegeln die Position zum Beispiel in einer RTL Umgebung nicht. An die neue Position gewöhnt man sich vermute ich recht schnell.
Das Problem ist die Position des Schließen Knopfs. Dieser ist in der Benutzung eines Fensters eigentlich der wichtigste und gravierendste. Die Maximieren Schaltfläche braucht man nicht so häufig und es gibt auch andere Möglichkeiten wie den Doppelklick auf die Fensterdeko um ein Fenster zu maximieren/wiederherzustellen. Gleiches gilt für die minimier Schaltfläche, die durch Klick auf den Eintrag in der Fensterleiste ersetzt werden kann.
Die Schließen Schaltfläche ist schwerwiegender. Ihre Aktion ist im Gegensatz zu allen anderen nicht umkehrbar. Ein geschlossenes Fenster kann idR nicht wiederhergestellt werden. Bei KWin ist daher in der Standarddekoration die Schließen Schaltfläche durch zwei explizite Spacer von den anderen Schaltflächen getrennt. Auch bei Aurorae hab ich mich für diesen großen Abstand entschieden. Es wurde übrigens auch schon darüber diskutiert die Schließen Schaltfläche komplett aus der Gruppe zu entfernen und auf die andere Seite zu platzieren. Leider sind solche Diskussionen ähm meistens suboptimal.
Andererseits scheint die Schließen Schaltfläche auch die zu sein, die die Nutzer am schnellsten erreichen wollen. Ich kann hier leider keine statistische Auswertung vorlegen und nur aus meiner Erfahrung sprechen. Wenn ein Fenster maximiert wird, so werden in Oxygen sämtliche Abstände zwischen den Schaltflächen und dem Bildschirmrand entfernt. Um ein Fenster zu Schließen muss man also nur mit der Maus in die rechte obere Ecke des Bildschirms klicken. Aurorae unterstützt aktuell dies noch nicht und es ist der häufigst gemeldete Bug, dass im maximierten Zustand Aurorae nicht Fitts’s Law respektiert. Jedes mal wenn mir das gemeldet wurde, ging es ausschließlich um den Schließen Knopf.
Nun was hat das mit der Ubuntu Fensterdeko zu tun? Die Schaltflächen wurden nach Links verschoben in der Anordnung: Minimieren, Maximieren, Schließen. Dies erinnert an Apple, dort ist jedoch die Schließen Schaltfläche ganz links. Was bedeutet das nun für den Nutzer? Das was man bei Aurorae am Stärksten kritisiert ist schlicht nicht möglich. Jedes mal wenn der Nutzer ein Fenster schließen will, muss er mit der Maus direkt auf die Schaltfläche fahren. Auch ist kein Sicherheitsabstand eingehalten was die Gefahr gibt, dass man die Schaltfläche aus Versehen auslöst.
So weit ich weiß erlaubt Metacity es dem User nicht die Positionen der Schaltflächen zu verändern (KWin erlaubt dies). Ubuntu will also eine LTS Version mit einem komplett geänderten Anordnung der Schaltflächen ausliefern. Eine Anordnung wie sie so in keiner größeren Umgebung genutzt wird (Windows, GNOME, XFCE und KDE setzen die Schließen Schaltfläche ganz nach rechts, Apple nach links). Es ist ja gut, dass am Design gespielt wird, jedoch sollte Design immer der Nutzbarkeit untergeordnet werden. Ich hoffe für Ubuntu, dass der Fehler erkannt und behoben wird, ansonsten fürchte ich werden die Supporter auf Ubuntuusers viel Arbeit haben. Ich bin bei solchen Aktionen immer wieder überrascht wie spät im Release Zyklus solch eine gravierende Änderung noch eingebaut wird.
=-=-=-=-=
Powered by Blogilo