Category: ubuntuusers

Bis zum Februar 2009 gab es eine wöchentliche Zusammenfassung aller KDE Commits im Commit-Digest. Danach hat Danny Allen die Arbeit alleine nicht mehr stemmen können. Mittlerweile arbeitet er daran es neu zu starten mit der Hilfe von vielen Freiwilligen und hat dazu eine Webplattform aufgebaut. Nun braucht es Freiwillige, die mitarbeiten die Commits durchzugehen und wichtige Commits herauszuheben. Mehr Infos dazu in Dannys Blog.

Der Commit-Digest ist ein unglaublich wichtiges Instrument, da er die KDE Entwicklung noch transparenter macht. Die Anwender können dadurch gut die Entwicklung verfolgen und sehen woran die Entwickler arbeiten. Ich erinnere mich daran, dass ich wöchentlich den Digest verfolgte als es zum KDE 4.0 Release ging und der Digest war somit ein wichtiger Faktor, dass ich überhaupt mit der Entwicklung begonnen habe.

Also hier nun auch von mir der Aufruf: helft bitte mit den Commit-Digest wieder mit Leben zu füllen! Danke.

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

Wie einige vielleicht wissen, haben wir in KDE Plasma Workspaces 4.5 leichte Probleme mit den freien Grafikkartentreiber. Die einzige Möglichkeit so etwas für die Zukunft zu verhindern, ist dass wir mehr testen und größere Änderungen am Rendering Stack nur zu Beginn des Release Zyklus implementieren, so dass diese etwa 6 bis 7 Monate getestet werden können. Ich selbst nutzte nun KWin von trunk und nicht mehr von branch um mögliche Probleme möglichst schnell zu bemerken. Dies kann man aber nur wenn man auch die freien Treiber benutzt. Und hier wird es problematisch:

Bis vor Kurzem war mein Hauptsystem ein Notebook mit einer NVIDIA 9600M. Eine andere Grafikkarte einzubauen ist durch die Tatsache "Notebook" schon mal nicht möglich. Man hat also die Wahl zwischen dem proprietären Treiber und Nouveau. Als Distribution setze ich Debian Testing aka Squeeze ein. Die Version von Nouveau in testing unterstützt nur 2D was den Ansprüchen eines Entwicklers am OpenGL Compositing Bereich nicht genügt. Da Squueze bereits Feature Frozen ist, wird sich da auf absehbare Zeit nichts ändern. Jedoch existiert auch eine neuere Version in experimental, welche auch die neuste Kernel Version aus experimental benötigt. Damit bekomme ich OpenGL zum Laufen, sogar GLSL funktioniert recht gut, jedoch ist der Treiber für den Einsatz auf einem Notebook noch ungeeignet, da die Stromsparmechanismen noch nicht vollständig implementiert sind. Die Akkulaufzeit ist deutlich schlechter und Suspend to RAM ist bei mir gescheitert. Somit leider wieder zurück zum NVIDIA Treiber.

Seit ein paar Wochen habe ich ein neues System mit einer ATI R710 Grafikkarte, die ich vor etwa zwei Jahren gekauft hatte um neben NVIDIA auch mit Mesa und fglrx testen zu können. Leider hat sich seit damals die Situation nicht wirklich verbessert – zumindest unter Debian Testing. Mit dem freien radeon Treiber erreiche ich maximal einen Kernel oops beim Starten vom X Server – ein wirklich schönes Bild man startet zum ersten Mal und sieht nur einen schwarzen Bildschirm und kann auch nicht auf ein Terminal wechseln. Mit den Treibern und Kernel aus X sieht es etwas besser aus: X startet zwar immer noch nicht aber es gibt zumindest keinen oops, aber in dmesg findet man einen Crash Trace. Nun ist Testing natürlich mit Mesa 7.7 etwas alt (meine Vermutung warum ich die Probleme in 4.5 mit dem Intel System das mir zum Testen zur Verfügung steht nicht reproduzieren kann, ist dass Testing zu alt ist) und man könnte Mesa von Hand bauen. Wenn man KDE baut, sollte man das wohl auch schaffen. Hmm Wiki etwas veraltet: "Under some newer distributions, like Ubuntu 7.04". Mit längerem Suchen findet man dann doch eine Anleitung die recht aktuell aussieht, jedoch möchte ich einfach nicht Dateien unter /usr austauschen und X zu erklären, wo es mesa findet will irgendwie nicht – zumindest ändert sich am Ergebnis nichts: kein X Server.

Nun gibt es ja nicht nur einen, sondern zwei freie Treiber: radeonhd. Diesen könnte man auch mal ausprobieren, also installiert, xorg.conf angepasst und kdm neugestartet und wieder nichts. Also Rechner komplett neustarten und siehe da, es gibt Verbesserungen: X startet zwar nicht, aber man fällt zumindest auf ein Terminal zurück. Mit Hilfe einer größeren Suchmaschine war das Problem schnell gefunden: radeonhd funktioniert nicht mit Kernel Mode Setting (KMS). Nur wie deaktivieren? Die Suchmaschine sagt was von "nomodeset" in grub übergeben, jedoch sieht man beim Hochfahren sehr schön, dass KMS aktiviert wird. Tja unter Debian wird KMS dynamisch aktiviert, wenn der radeon Treiber geladen wird. Man muss also die Datei /etc/modprobe.d/radeon-kms.conf anpassen (völlig offensichtlich, oder?), danach startet auch X und siehe da, es wurde Farbe. Nur mein primärer Bildschirm hatte leicht verzehrte Farben. Login und sogar Desktopeffekte sind aktiv und nach Spielen mit XRandR sind die Bildschirme korrekt eingerichtet, nur wird der falsche Bildschirm als primär angesehen – aber OK. Leider ist die OpenGL Version nur 1.5 und da KMS ja nicht unterstützt ist, funktionieren Funktionen wie Shader (ARB und GLSL) und Framebuffer Objects leider nicht. Keine guten Voraussetzungen für die KWin Entwicklung mit diesem Treiber. Damit hätte ich noch arbeiten können, jedoch gab es leichte Probleme nach dem Suspend Test: der größere der beiden Bildschirme wollte einfach nicht mehr. Egal was ich in XRandR eingestellt hatte, ließ er sich nicht dazu überreden etwas anzuzeigen. Dieser Fehler hat sogar erfolgreich einen Neustart von X überlebt.

Tja da steh ich nun ich armer Tor und bin so klug als wie zuvor. Auf beiden Systemen läuft wieder der proprietäre BLOB. In der Gesmatheit meiner Feature Anforderungen sind die proprietären Treiber für mich weiterhin die einzige Wahl, kurz zusammengefasst gibt es folgende Showstopper:

• Nouveau überlebt Suspend auf Notebok nicht
• Radeon endet in Kernel oops
• Radeonhd mag meinen Full-HD Bildschirm nicht

Nun gäbe es noch eine Möglichkeit das ganze Problem auf die Distribution zu schieben: laut der Meinung einiger Leute im Phoronix Forum sei das ja der Hauptgrund für die Probleme in 4.5, da ich die falsche Distribution nutze. Jedoch habe ich in regelmäßigen Abständen die Ati Karte mit verschiedenen Distributionen ohne Erfolg getestet. Zuletzt auch Kubuntu Maverick Beta, diese sollte ja das neueste mitbringen, was es so aktuell gibt. Und ja, X startet, jedoch startet X sich auch neu, wenn man Desktop Effekte aktiviert. Also kann ich auch bei einer Distribution bleiben, welche ich kenne und schätze. Rolling Release ist für mich undenkbar, da Treiber Probleme implizieren, dass ich nicht mehr an KWin entwickeln kann. Ein gewisses Grad an Stabilität benötige ich halt doch

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

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

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

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

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