Hinweis:
Dieser Kommentar stellt die persönliche Meinung des Autors dar und nicht die Meinung irgendwelcher Projekte, in die er involviert ist (einschließlich ubuntuusers.de).
Notify-OSD sowie die KDE Implementierungen werden vom sogenannten Ayatana Projekt 🇬🇧 vorangetrieben, einer Entwicklergruppe von Canonical. Die ursprünglichen Ideen waren auf den GNOME Desktop ausgerichtet und sollten einige der dort existierenden Probleme beheben. Diese Probleme existierten im KDE Desktop jedoch nie. KDE hat schon seit langem ein sehr mächtiges Benachrichtigungsframework namens KNotify. Jede mögliche Benachrichtigung einer Anwendung ist individuell konfigurierbar, so ist es möglich Benachrichtigungen anzeigen zu lassen, einen Ton abzuspielen, den Eintrag in der Fensterleiste hervorzuheben, die Benachrichtigung zu protokollieren oder sogar ein externes Programm auszuführen. Mit wenigen Mausklicks kann man eine nervende oder störende Benachrichtung einfach deaktivieren.
Seit KDE 4.2 wurden die Benachrichtigungen in die Desktop Shell Plasma integriert. Zu dem Zeitpunkt als Ubuntu mit Notifiy-OSD ausgestattet wurde, erhielt auch KDE optisch aufgefrischte Benachrichtigungen. Mit dem kleinen Unterschied, dass bei KDE die Entwickler und nicht eine Distribution die Änderung umgesetzt haben und die Anwendungen nicht verändert werden mussten. Für die GNOME Implementierung müssen die existierenden Anwendungen angepasst werden.
 |
| Einstellungen von Benachrichtigungen |
Die Umsetzung in Plasma war sicherlich nicht perfekt und die Entwickler haben für KDE 4.3 einige Überarbeitungen und Verbesserungen vorgenommen. Dies wurde öffentlich über die Mailinglisten diskutiert, zusätzlich wurden die Patches auf dem KDE Reviewboard geprüft. Jeder hätte die Möglichkeit gehabt, sich an der Diskussion zu beteiligen und eigene Standpunkte einzubringen und Verbesserungen vorzuschlagen. Dies hätte auch das Ayatana Projekt machen können.
Stattdessen hat Canonical sich das Ziel gesetzt die „Verbesserungen“ von Notify-OSD nach Upstream zu bringen und hat dazu einen KDE Entwickler angestellt, jedoch keinen KDE Workspace Entwickler. Ayatana hat nun sprichwörtlich das Rad neu erfunden und Notify-OSD für KDE implementiert. Ein zusätzliches Benachrichtigungssystem welches faktisch das gleiche bietet. Die einzigen Unterschiede für den Nutzer optischer Natur: Die Notify-OSD Benachrichtungen lassen sich frei platzieren. Dies in das KDE Benachrichtigungssystem einzubauen grenzt an Trivialität.
Der größte Unterschied zwischen den beiden Systemen ist für den Anwender nicht ersichtlich: Notify-OSD bietet keine Aktionen in den Benachrichtigungen. Wird eine Benachrichtigung mit einer Aktion gesendet so wird ein Dialogfenster angezeigt. Diese Einschränkung wurde von Seiten der KDE Entwickler von Anfang an kritisiert und abgelehnt 🇬🇧 . Es ist klar, dass es da keine Einigungen geben wird. So spricht der Plasma Hauptentwickler von „grundlegenden Unterschieden in Design und Erwartungen“. Ayatana wird von KDE als Inselprojekt wahrgenommen, welches keine Partizipation erlaubt auf die Kritikpunkte wird nicht eingegangen. Es ist natürlich Canonicals gutes Recht Ayatana intern zu entwickeln. Genauso ist es KDEs gutes Recht die Entwicklung abzulehnen.
Die Plasma Benachrichtigungen haben das Ziel den Arbeitsfluss des Anwenders nicht zu unterbrechen und folgen dem Kein-Dialog Ziel für die Desktop Shells. Das Problem mit Dialogen ist, dass diese aus Versehen aktiviert werden können. Ein Dialog öffnet sich – wie der Name schon nahe legt – im Dialog mit einer Anwendung. Ein Dialog welcher nicht durch eine Interaktion des Nutzers geöffnet wird, ist daher falsch und der Fenstermanager verhindert zum Beispiel, dass dieser fokussiert werden kann.
Nun sieht die Ayatana Implementierung vor, dass Dialoge anstelle von Aktionen in Benachrichtigungen angezeigt werden. Natürlich sehen auch die Canonical Entwickler, dass es eine schlechte Idee ist, wenn der Chat Client bei jeder neuen Nachricht einen Dialog öffnet. Eine Aktion in der Benachrichtigung ist hier jedoch sehr sinnvoll. Durch einen einzelnen Klick kann man zu der Chat Anwendung springen, egal auf welchem Desktop sie sich befindet, um zu antworten. Möchte man nicht antworten so ignoriert man die Benachrichtigung und sie verschwindet wieder im Systemabschnitt. Trotzdem kann man jeder Zeit über den Systemabschnitt die Benachrichtigung wieder hervorbringen und die Aktion auslösen. Man ist nicht auf sofortiges Reagieren angewiesen und kann darauf vertrauen, dass auch in ein paar Minuten die Benachrichtigungen noch aufrufbar sind.
 |
| Native KDE Benachrichtungen vs. Ayatana |
Dass Ayatana keine Aktionen unterstützt und KDE Anwendungen viele Aktionen verwenden, führt zu amüsanten Entwicklungen. In unregelmäßigen Abständen erscheinen nun Patches von Seiten Canonicals um das „Problem“ zu lösen. Entweder sollen die Anwendungen einzeln überprüfen, ob der Benachrichtigungsprozess Aktionen unterstützt 🇬🇧 , dann sollen sie global verworfen werden oder die Benachrichtigung direkt durch einen Dialog ersetzt werden. Das Problem ist natürlich von Canonical hausgemacht durch die Weigerung Aktionen zu unterstützen. Die Änderungsvorschläge treffen nicht auf Gegenliebe und obwohl KDE mehrmals die Patches abgelehnt hat, werden immer wieder neue Versuche gestartet. Interessant dabei ist auch, dass Themen welche eigentlich nur die Desktop Shell betreffen an die globalen Mailinglisten gesendet werden, auf denen auch die Entwickler, welche nicht so sehr in die Materie des Desktop Designs involviert sind, mitlesen und kommentieren. Man könnte vermuten, dass hier ein Versuch gestartet wurde über Entwickler, welche die Idee auf Grund fehlenden Wissens (so wird einfach mal vergessen darauf hinzuweisen, dass Canonicals Implementierung keine Aktionen unterstützt) für gut halten, Druck auf die Plasma Entwickler auszuüben.
In dem Punkt der Anzeigedauer unterscheidet sich Ayatana ebenfalls von der KDE Umsetzung. Bei Ayatana verschwinden die Benachrichtigungen einfach, bei KDE sind sie wieder aufrufbar. Da das nicht gut ist, musste ein neues Rad erfunden werden namens „Indikatoren“ 🇬🇧 . Dies ist im Falle von Kubuntu ein Plasmoid welches Nachrichten aus Chat, IRC und Emailprogramm anzeigt. Das Plasmoid befindet sich standardmäßig in der Kontrollleiste und wird auch angezeigt, wenn es keine neuen Nachrichten gibt. KDE hat für so etwas eigentlich die Notification Area (aka Systemabschnitt) geschaffen, welche es den Anwendungen ermöglicht Informationen nur anzuzeigen, wenn es etwas anzuzeigen gibt. So könnte das EMail Programm sein Icon ausblenden, wenn es keine Icons gibt. Ayatana schafft 🇬🇧 hier also erneut eine Lösung zu einem Problem, welches schon längst gelöst ist und seit 4.3 experimentell integriert ist und in 4.4 standardmäßig vorhanden sein wird und als neue Spezifikation auf freedesktop.org 🇬🇧 eingereicht ist. Ayatana hätte sich auch hier an der Entwicklung direkt beteiligen können.
Das größte Problem aber an den Indikatoren ist, dass der Quelltext angepasst werden muss. Jede Anwendung, welche Indikatoren verwenden soll, muss angepasst werden. Dies entspricht in keinster Weise der Art und Weise wie KDE Software implementiert wird. KDE setzt auf globale Lösungen: einmal schreiben, oft wiederverwenden. Für die Entwickler ergibt es auch das Problem, dass sie Code aufnehmen sollen für eine einzelne Distribution. Wenn jede Distribution ihr eigenes Süppchen kocht, wird so etwas nicht wartbar und verschlechtert die Code Basis.
Mit Kubuntu 9.10 werden die Indikatoren standardmäßig Einzug halten, die neuen Benachrichtigungen jedoch nur als optionales Element. Es soll getestet werden, wie die KDE Anwender damit zurechtkommen. Ob in zukünftigen Versionen das System den Anwendern „aufgezwungen“ wird, lässt sich aktuell noch nicht sagen. Es ist jedoch durchaus enttäuschend, dass Canonical auf die Kritik von KDE nicht eingeht und trotz der ablehnenden Haltung an dem Konzept festhält und die Fehler im Design nicht behebt. Das Ayatana Projekt hätte sich aktiv an den KDE Designs beteiligen können, stattdessen wurde das Rad neu erfunden und neuer Quelltext geschrieben 🇬🇧 . Dadurch dass der Quelltext nicht in Upstream einfließen wird, unterliegt er auch nicht der Qualitätskontrolle von KDE. Eine Änderung dieses Umfangs würde normalerweise im Reviewprozess überarbeitet werden. Dies ist nun nicht gegeben. Dennoch werden die Anwender den Quelltext verwenden und mögliche Fehler werden auf Grund von Unwissenheit KDE und nicht Canonical angekreidet. Es ist auch nur eine Frage der Zeit, bis die ersten Forenthreads erscheinen, in denen Anwender sich beschweren, dass sie keine Aktionen mehr in ihren Benachrichtigungen haben.
Vielen Dank an martingr für diesen ausführlichen Artikel!
