Fredo's Blog

Vor Kurzem hat martingr für Ikhaya einen Artikel zu Kubuntu und Notify-OSD geschrieben. Darin beleuchtet er Nachteile von Ubuntus Notify-OSD gegenüber KNotify. Die Integration von Notify-OSD in KDE sei daher ein Rückschritt gegenüber den Fähigkeiten, die KDE von Haus aus mitbringt.

Die Situation in KDE kann ich als GNOME-Nutzer gar nicht beurteilen. Aber auch der Einzug von Notify-OSD in GNOME, das mit notification-daemon ja ebenfalls ein eigenes Benachrichtigungssystem hat, sorgte für einige Diskussionen. Wie so oft ist vieles natürlich Ansichtssache, und einige Positionen lassen sich auch nicht miteinander in Einklang bringen. Um den Meinungsbildungsprozess ein bisschen ausgewogener zu gestalten, möchte ich an dieser Stelle einmal ein paar Argumente pro Notify-OSD anführen.

Dass ich dabei Martins Ausführungen zum Anlass nehme, soll dabei nicht heißen, dass ich seine Position für falsch halte. Aber in der Gegenüberstellung von Argument und Gegenargument lassen sich vielleicht einige Punkte verdeutlichen.

Argument 1: Für Notify-OSD müssen bestehende Anwendungen gepatcht werden.

Martin schreibt über die GNOME-Version von Notify-OSD:

Für die GNOME Implementierung müssen die existierenden Anwendungen angepasst werden.

Das Argument scheint auf den ersten Blick schwer zu entkräften, schaut man sich die lange Liste von Anwendungen an, die noch gepatcht werden müssten, um mit Notify-OSD kompatibel zu sein.

Wozu genau sind aber diese Anpassungen notwendig? Es geht, wie auch Martin schreibt, darum, dass Notify-OSD keine Actions unterstützt, also in die Benachrichtigung eingebettete Buttons. Ist damit nicht Notify-OSD unvollständig, und sollte nicht lieber dieser Bug in Notify-OSD behoben werden, anstatt alle Anwendungen anzupassen? An dieser Stelle kommen Standards und desktopübergreifende Spezifikationen ins Spiel: notification-daemon und KNotify implementieren eine Spezifikation des Galago-Projekts. Das ist auch sehr nützlich, denn so funktionieren Benachrichtigungen unabhängig vom Desktop.

Warum implementiert Notify-OSD diese Spezifikation dann nicht? Denn offenbar ist Notify-OSD ja umständlicher als die bisherigen Systeme. Der Eindruck entsteht zumindest, wenn Martin schreibt, es

sollen die Anwendungen einzeln überprüfen, ob der Benachrichtigungsprozess Aktionen unterstützt, dann sollen sie global verworfen werden.

Doch dies ist genau das, was die Spezifikation vorsieht: Nicht alle Implementierungen müssen alle möglichen Details umsetzen. Statt dessen gibt es eine Methode, mit der Anwendungen abfragen können, welche Fähigkeiten sie voraussetzen können, und welche nicht.

Damit muss man es also eigentlich genau andersherum formulieren: Die Änderungen, die die Ubuntu-Entwickler an den Anwendungen vornehmen, sind Bug-Fixes. Diese Bugs bestehen darin, dass die Anwendungen die Spezifikation nicht korrekt umsetzen, sondern sich daran orientieren, was de facto von den beiden bisherigen Implementierungen dieser Spezifikationen unterstützen. Das entspricht aber gerade nicht dem Sinn solcher Spezifikationen.

Warum aber implementiert Notify-OSD nicht einfach diese Aktionen in Benachrichtigungen? Das hängt mit dem zweiten Punkt zusammen:

Argument 2: Notify-OSD zeigt störende Dialoge, während KNotify ohne Dialoge auskommt.

Es geht bei dieser These um den Fall, dass eine Benachrichtigung eine direkte Aktion des Benutzers ermöglichen soll. Bisherige Benachrichtigungssysteme betten in diesem Fall einfach einen Button in das Benachrichtigungsfeld ein. Martin schreibt hierzu:

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.

Es bietet sich aber auch eine ganz andere Deutung an: Die Benachrichtungsfelder von KNotify (und übrigens auch von notification-daemon) sind eigentlich Dialoge. Sie haben zwar keine Fensterrahmen, aber sie bieten die Möglichkeit zur Interaktion mit dem Benutzer an. Die angesprochenen eingebetteten Buttons sind genau ein solcher Fall. Das Argument, dass solche Buttons versehentlich aktiviert werden können, trifft also auf klassische Dialoge ebenso zu wie auf Notification-Felder mit Buttons.

Die Entscheidung, Actions in Notify-OSD nicht zu implementieren, ist deswegen die eigentliche Neuerung: Ein Benachrichtigungssystem soll Benachrichtigen, aber eben keine Interaktionen ermöglichen. Deswegen kann man auch durch eine Benachrichtigung von Notify-OSD „hindurchklicken“. Praktisch etwa, wenn man ein Fenster schließen will, während oben rechts eine Benachrichtigung erscheint. Man klickt nicht versehentlich auf die plötzlich auftauchende Benachrichtigung, sondern, wie beabsichtigt, auf den Schließen-Knopf des Fensters.

Deswegen hat Martin auch die Ideen des Projektes etwas verzerrt wiedergegeben:

Nun sieht die Ayatana Implementierung vor, dass Dialoge anstelle von Aktionen in Benachrichtigungen angezeigt werden.

Die Implementierung zeigt Dialoge an, falls Anwendungen (fälschlich, wie ich oben dargestellt habe) Aktionen vorsehen, ohne die Fähigkeiten der Implementierung abgefragt zu haben. Damit ist das Anzeigen von Dialogen anstelle der Aktionen gerade nicht gewollt, sondern eine Übergangslösung für fehlerhafte Anwendungen. Bei der Implementierung von Notify-OSD wurde gerade sehr darauf geachtet, möglichst gut in der aktuellen Situation zu funktionieren, ohne die Vorteile des neuen Systems aufzugeben.

In einem Punkt muss ich Martin jedoch Recht geben: Auch ich bin nicht wirklich überzeugt davon, ob die vorgesehene Dauerlösung mit den Indikator-Applets wirklich der beste Weg ist. Es ist das eine, eine spezifikationskonforme Implementierung eines Standards zu entwickeln. Es ist aber etwas anderes, ein eigenes Aktions-System zu entwerfen, was von den Anwendungen upstream umgesetzt werden soll, ohne dass dieses System mit breiterer Beteiligung verschiedener Projekte entwickelt und spezifiziert wurde.

Ein Vorschlag für eine Spezifikation besteht, und es werden auch Kommentare erbeten. Um wirklich breite Akzeptanz für die meiner Auffassung nach richtige Idee zu finden, sollte der Prozess aber deutlicher von Ubuntu gelöst werden. Vielleicht wäre Freedesktop.org ein geeigneterer Ort für diese Diskussion als das Ubuntu-Wiki.

Vor kurzem ist die neue Version 1.3.5 von Scribus erschienen. Diese ist zwar als Entwicklerversion ausgewiesen (deswegen ScribusNG), ist aber schon vergleichsweise stabil und bringt einige verbesserte und neue Features mit, die einen Testlauf rechtfertigen.

Während Firefox oder Googles Chrome trotz marginaler Änderungen ihre Versionssprünge mit Siebenmeilenstiefeln machen, stecken bei Scribus zwei Jahre Arbeit hinter der Änderung in der dritten Stelle der Versionsnummer. Und diese Arbeit sieht man auch. So wurde Scribus auf Qt4 portiert. Dies hat für GNOME-User den großen Vorteil, dass sich Scribus dank QGtkStyle nun erstmals sehr hübsch in den Desktop einfügt. Dieser positive Eindruck wird durch die Tango-Icons bestätigt. Aber auch darüber hinaus wurde die optische Erscheinung stark aufgewertet, Objekte auf dem Canvas sehen deutlich besser und moderner aus.



Aber auch einige Funktionen wurden um schon lange vermisste Features erweitert. So wurden die Möglichkeiten der Stile deutlich erweitert: Neben Absatzstilen sind jetzt auch endlich Zeichenstile möglich, und Stile können ihre Eigenschaften vererben. Diese etwa aus OpenOffice.org bekannten Funktionen werden bei Scribus aber noch eine Stufe weiter getrieben: Absatzstile können auch von Zeichenstile erben.

Neben diesen verbesserten Funktionen gibt es aber auch ganz neue Features. So wurde gerade die Arbeit im Pre-Press-Bereich stark vereinfacht: So lässt sich direkt in den Dokumenteneigenschaften ein Anschnitt definieren. Der PDF-Export erlaubt, Schneidemarken, Registrierungsmarken und ähnliches hinzuzufügen.

Ein neues, sehr interessantes Feature, das ich aber noch nicht ausprobiert habe, sind die sogenannten »Render Frames«. Hier kann man Befehle aus LaTeX und anderen Sprachen angeben, die im Dokument dann durch ihren Output ersetzt werden. So lassen sich dann z.B. mathematische Formeln sehr einfach integrieren. Könnte auch interessant sein, um Grafiken aus R einzubinden.

Wie man vielleicht merkt, bin ich vom neuen Release ziemlich begeistert. Während Scribus für mich bisher schon durch seinen guten PDF-Output überzeugte, aber sonst eher unsexy war, kommt das Programm jetzt schon dem sehr nahe, wie ich mir ein DTP-Programm vorstelle. Auf die stabile Version 1.4 freue ich mich jetzt schon. Der einzige Wermutstropfen ist, dass Ubuntu Hardy noch eine zu alte Qt4-Version mitbringt, und es daher keine Pakete der neuen Scribus-Version gibt. Jetzt muss ich mir überlegen, am Arbeitsplatz doch mal auf Jaunty zu aktualisieren – denn auf den zusätzlichen Komfort möchte ich nur ungern missen.

Nur auf die Schnelle ein kurzer Post:

Heute habe ich endlich erste Schritte mit XeTeX gewagt. Irgendwie ist man ja pdfTeX gewohnt, und schon allein aufgrund der vielen verfügbaren Anleitungen hält sich das wohl noch einige Zeit. Aber XeTeX ist schon einen Blick wert: Vor allem die Verwendung der System-Schriften macht es wesentlich komfortabler, beliebige Schriften zu verwenden, als mit pdfTeX. Und die echte Unicode-Unterstützung ist Gold wert.

Nur benutze ich gerne rubber zum Kompilieren von LaTeX-Dokumenten. Dies unterstützt XeTeX jedoch noch nicht. Die Lösung ist jedoch recht einfach. Man erstellt einfach eine Datei »xetex.py« im Verzeichnis »/usr/share/rubber/rubber/rules/latex/«. In diese kopiert man folgenden Text:

# This file is part of Rubber and thus covered by the GPL
# (c) Emmanuel Beffara, 2002--2006
# (c) Frederik Elwert, 2009
"""
XeLaTeX support for Rubber.

"""

import rubber

class Module (rubber.rules.latex.Module):
        def __init__ (self, doc, dict):
                doc.vars["program"] = "xelatex"
                doc.vars["engine"] = "XeTeX"
                doc.prods = [doc.src_base + ".pdf"]

Nun kann man mit folgendem Befehl XeTeX-Dokumente übersetzen:

rubber -m xetex datei.tex

Bei einem ersten Test hat es problemlos geklappt, hoffen wir also mal das Beste.

Update:

Wie towolf netter Weise bemerkt hat, reicht auch eine Angabe im Kopf der LaTeX-Datei:

% rubber: set program xelatex

Das ist natürlich sehr praktisch, dieses Feature kannte ich noch gar nicht. Danke für den Hinweis!

GNOME bringt ja eine Reihe ganz netter Spiele mit. Gerade die Kartenspiele glänzen jedoch nicht gerade durch ein hübsches Design. Das Kartenset Ornamental aus dem Paket gnome-games-extra-data gefällt mir ganz gut, ist aber sicherlich nicht für jeden was. Aber vielleicht könnte man der Königin ja Tango beibringen?

Read more...

In der Tat, Zotero hat mich weitgehend überzeugt. Es ist ein recht brauchbares Literaturverwaltungsprogramm, vor allem aber wird es aktiv weiterentwickelt und von etablierten Institutionen unterstützt. Damit ist es eine recht zukunftssichere Wahl, schließlich will ich nicht alles halbe Jahr meine Literaturdatenbank umziehen.

Die Integration in OpenOffice.org ist außerdem wirklich gut. Nur schreibe ich eigentlich lieber mit LaTeX, und hier bietet Zotero von Haus aus keine Unterstützung. Aber gedit, mit dem LaTeX-Plugin mein favorisierter LaTeX-Editor, hat ja eine schöne Python-Plugin-API. Also kann man ja mal versuchen, ein gedit-Plugin für die Zotero-Einbindung zu schreiben…

Read more...