Opensuse 12.3 – OpenClipart-Definitionen für Libreoffice unvollständig

Ich habe ja vor kurzem auf zwei Systemen Opensuse 12.3 installiert. Im Zuge davon habe ich auch ein Update der Libreoffice-Installation vorgenommen. Danach wollte ich im Rahmen eines Projektes mit Hilfe der Clipart-Gallery ein paar Draw-Zeichnungen anfertigen. Die notwendigen Clipart-Pakete

  • libreoffice-openclipart
  • openclipart-svg (in der Version 0.18

hatte ich natürlich installiert.

Zur Voransicht der Cliparts gibt es in den Libreoffice-Anwendungen ein Fenster, in dem die Cliparts nach thematischen Bereichen gegliedert dargestellt werden. Soweit ich mich erinnern kann, hatte ich dort zumindest in einer OS 12.1 / LibreOffice 3.5-Installation für alle Themenbereiche der Gallery auch eine Voransicht zugehöriger Ciparts gefunden.

Leere Ansicht für viele Gallery-Themenbereiche unter OS 12.2 und OS 12.3

Leider wird nun für die meisten thematischen Gallery-Bereiche in Libreoffice 3.5 bis 4.0.2 unter Opensuse 12.2 oder Opensuse 12.3 gar nichts mehr angezeigt. Beispiele liefern "Science" oder "Shapes" ; im Gallery-Fenster ist zu beiden Themenbereichen kein Clip zu sehen:

gallery_leer_600

Das ist ein typischer Mangel an qualitätsgesicherter Paket-Aufbereitung, wie er mich an der Verbreitung von Opensource-Produkten durch einige Distributoren manchmal an den Rand der Verzweiflung treibt. Was macht denn eine normaler Anwender bei einem solchen Befund? Er zuckt mit den Achseln, wundert sich und geht davon aus, dass es da halt keine Bilder gibt. das ist zugleich falsch und schade!

Eine Fehlersuche zeigt, dass es im Verzeichnis /usr/lib64/libreoffice/share/gallery/ Softlinks auf *sdg-Dateien gibt, die im korrespondierenden Verzeichnis /usr/share/libreoffice/share/gallery/ leider ins Nirwana führen. Für die entsprechenden Themenbereich wird in der Clipart-Ansicht der Libre-Office-Bereiche deshalb nichts angezeigt, obwohl im thematischen Subverzeichnis unter /usr/share/openclipart/ haufenweise svg-Dateien vorhanden sind.

Ein Blick in die Verzeichnisliste des Openclipart-Pakets von Opensuse zeigt, dass die beschreibenden "sdg"-Dateien für viele Themenberieche tatsächlich nicht ausgeliefert werden - also bereits im RPM-Paket von Opensuse selbst fehlen. Warum auch immer .... Ein Bug?

Eine parallele Windows-Installation ist wenigstens ehrlicher - die bietet von Haus aus nur wenige gefüllte Themenbereich an. Den Rest muss man sich sowieso selbst zusammenstellen.

OpenClipart-Download als Alternative ? Nein !

Alternativ und naiv dachte ich nun daran, mir etwas von der OpenClipart-Seite im Web herunterzuladen. Da wurde alles nur schlimmer; ein Download aktuellerer Clipart-Pakete ab Version 0.19 führt in den Abgrund.

Man erhält dann nämlich keine vorsortierte thematische Zusammenstellung an Files mehr, die man in ein Subverzeichnis von "/user/share/clipart/" einfügen könnte. Stattdessen kommen HTML-Dateien mit Bildern aus einem Verzeichnis, das nach allen möglichem (u.a. Autoren) aber nicht thematisch untergliedert ist. Vielmehr wird hier eine komplexe Installation von HTML-Seiten mit PHP-MySQL-basierter Suchmaschine erwartet. Leider funktioniert das vorgesehen "make install" unter OS 12.3 gar nicht. Schauder ... - in dieser Form ist OpenClipart 2.x weder für LibreOffice noch sonst irgendwie brauchbar. Keine Zeit, mich damit zu befassen. Ich will doch nur ein paar faktisch vorhandene Cliparts unter Libreoffice sehen und nutzen!

Workaround

Ich habe dann versuchsweise Libreoffice komplett deinstalliert, alle zugehörigen Konfigurationsdateien in meinem Home-Verzeichnis entfernt und Libreoffice neu installiert. Das half leider auch nichts. Aus Zeitmangel habe ich nun einen Workaround per Handarbeit vorgenommen:

Schritt 1: Man muss in Libreoffice im Gallery-Fenster selbst ein neues Thema zu einem der vorhandenen thematischen, aber leider als leer angzeigten Bereiche wie "Shapes" anlegen. Ich gebe dem neuen Thema z.B. den Namen "shapes_2".

Schritt 2: Im Subdialog-Fenster zu diesem neuen Thema lässt man im thematischen Unterverzeichnis von /usr/share/openclipart/ [hier also im Verzeichnis "/usr/share/clipart/openclipart/shapes/" ] alle passenden Dateien zusammensuchen, markiert dann alle oder eine Unterauswahl und drückt auf den Button "Hinzufügen". Die Anzeige des folgenden kleinen Dialoginhalts ist unter meinem KDE 4.10 dann leider nicht vollständig zu erkennen - aber man wartet einfach, bis der Übernahmeprozess erfolgt ist.

Schritt 3: Das Ergebnis sind dann 3 Dateien unter /home/USER/.config/libreoffice/4-suse/user/gallery/ (USER ist dabei dein Username):

  • sgxxx.sdg,
  • sgxxx.thm,
  • sgxxx.sdv

xxx steht dabei für eine 2- oder dreistellige Ziffer. Das eben installierte Clipart-Thema hat die höchste Nummer.
Man wird in unserem Beispiel feststellen, dass Libreoffice nun im Gallery-Fenster unter "shapes_2"alle svg-Dateien von "/usr/share/clipart/openclipart/shapes/" tatsächlich anzeigt. Die drei beschreibenden Dateien, im besonderen die sdg-Datei, sind dafür hinreichend.

Schritt 4:
Nun ermittelt man unter Libreoffice im Galleryfenster durch einen Rechtsklick auf das ursprüngliche "Shapes" dessen "Eigenschaften". In einem Dialofenster wird u.a. ein File-Pfad und ein File-Name einer zugehörigen Deskriptionsdatei sgxxx.sdg angezeigt - bei mir ist Shapes z.B. mit dem File "sg85" assoziiert.

Man fertige nun eine Kopie der obigen drei Dateien sgxxx.sdg, sgxxx.thm, sgxxx.sdv an und benenne die Ziffern "xxx" in "85" (bzw. die eben ermittelte Nummer) um. Danach verschiebe man diese deskriptiven Dateien als root (!) in das Verzeichnis "/usr/share/libreoffice/share/gallery/". (Root-rechte sind dort zum Schreiben erforderlich.

Danach funktioniert auch die Anzeige der Dateien unter dem ursprünglichen Themenbereich "Shapes" und nicht nur unter "shapes_2".

gallery_voll_600

Den für den Workaround angelegten Themenbereich "shapes_2" kann man nun eigentlich auch löschen löschen. Ich würde ihn aber behalten, da die Deskriptonsdateien für "Shapes" bei einer Neuinstallation der Opensuse-RPMs möglicherweise wieder gelöscht werden. Dann kann seine alte Auswahl im Eigenschaftsdialog von shapes_2 aktualisieren lassen und wie oben beschrieben weiterverfahren.

Nach diesem kleinen Desaster zur Korrektur einer unvollständigen OpenClipart-V18--Installation unter Opensuse 12.3 bleibt abzuwarten, wie Opensuse und LibreOffice mit der Integration von OpenClipart-Galleries der aktuellen Versionen 0.19 und 2.X umgehen werden.

Libreoffice 3.4, Scrollbar-Fehler, KDE 4.7

Manchmal gibt es in der Opensource-Welt Fehler, über die man sich aus folgenden Gründen wirklich ärgern muss:

  • Sie brechen nach Wochen halbwegs angenehmen Arbeitens plötzlich aufgrund eines harmlos erscheinenden Updates einer Applikations-Sub-Version über einen herein und machen eine Schlüsselapplikation zumindest teilweise unbrauchbar.
  • Sie sind spezifisch für eine Linux-Desktop-Variante (hier KDE 4.7.x) und treten unter einer anderen (KDE 4.6, Gnome) nicht auf.
  • Die Entwickler und Distributoren haben die verschlimmbesserten Anwendungs-Programme offenbar nicht unter der betroffenen aktuellen Desktop-Versionen getestet.

In diese Kategorie fallen z.B. zwei aktuelle Fehler bzgl. der Integration von Libreoffice 3.4.x und KDE 4.7.x - zumindest unter Opensuse 11.4, wohl aber auch unter anderen Distributionen.

Libreoffice ist GTK-basiert. GTK-Applikationen laufen unter KDE vom Erscheinungsbild her leider nicht immer ganz optimal. Aber im vorliegenden Fall half kein Rumdoktern an Einstellungen oder der Austausch von Bibliotheken für die GTK-QT-Integration; es liegt wohl eher ein Bug vor.

Man betrachte folgendes Bild:

bug libreoffice 600

Man erkennt einerseits eine viel zu große ungeglättete Schriftart, die zur Beschriftung der Lineale herangezogen wird. Andererseits - und das ist schlimmer - liegt ein Teil der Dokumentdarstellung über dem horizontalen Scrollbar, der dadurch letztlich unbrauchbar wird.

Bzgl. der Linealbeschriftung gilt, dass offenbar nicht die KDE-Schriften gezogen werden, obwohl in der entsprechenden LibreOffice-Optionen-Seite

"Extras > Optionen > LibreOffice > Ansicht"

der Punkt

"Systemschriftart für die Benutzeroberfläche wählen"

aktiviert ist. Statt dessen wird auf eine Schrift zurückgegriffen, die auf dem Linuxdesktop nicht unterstützt ist. Zumindest auf meinem nicht - und da sind wirklich viele Schriften installiert ...

Beim horizontalen Scrollbar klappt möglicherweise die Integration der gewählten GTK-Styles unter KDE 4.7 in Libreoffice nicht, obwohl ein ansprechender Style unter KDE4's "Systemeinstellungen > GTK-Stile und Schriftarten" ausgewählt wurde - und bei anderen GTK-basierten Anwendungen auch gezogen wird. Oder es liegt halt ein anderer handfester Bug vor.

Ein Test unter Gnome und KDE 4.6 zeigt im Gegensatz zu KDE 4.7 interessanterweise eine einwandfreie Darstellung der Libreoffice-Oberfläche.

Workaround

Als Sündenbock entpuppt sich nach ein wenig Rumspielen schließlich das RPM-Paket "libreoffice-kde4". Ein Workaround besteht entsprechend darin, dieses Paket durch "libreoffice-gnome" zu ersetzen und die Einstellungen für die Gnome-Oberfläche zu erzwingen, obwohl man unter KDE4 arbeitet.

Dies geschieht dadurch, dass man in die Datei "/usr/bin/soffice" folgende Zeile einfügt:

export OOO_FORCE_DESKTOP=gnome soffice

Danach kann man mit Libreoffice 4.4.x unter KDE 4.7.x wieder arbeiten. Sogar die KDE-Schriftarten werden für die Menüs gezogen, wenn man einen kompletten Neustart der KDE-Oberfläche vornimmt.

Dieser Umweg ist nicht auf meinem Mist gewachsen - gefunden habe ich den Vorschlag nach einer etwas mühsamen Suche im Internet unter

https://bbs.archlinux.org/viewtopic.php?pid=971669

Ich dachte, ich verweise an dieser Stelle mal auf diesen Workaround, denn in vielen Internet-Beiträgen zum Scrollbar-Problem gehen die verzweifelten Anwender entweder auf eine ältere Libreoffice Version oder gar auf eine ältere KDE-Version zurück. Das ist unnötig. Aber die Verzweiflung der Anwender verstehe ich gut, denn es handelt sich bei KDE 4.7 und Libreoffice 3.4 ja um fundamentale Bausteine eines Opensource-Desktops, die man zum produktiven Arbeiten benötigt.

Mangelnde Qualitätssicherung ?

Es bleibt wieder der ungute Eindruck, dass es vor der Veröffentlichung mancher "verbesserter", neuer Versionen von Opensource-Programmen an der Qualitätssicherung hapert. Im aktuellen Fall haben sich die Entwickler wohl mehr um Gnome, ältere KDE-Versionen oder gar Windows als Zielplattform gekümmert. Einen Test für ein aktuelles KDE 4.7 kann wohl kaum jemand durchgeführt haben, denn sonst gäbe es nicht so viele Beiträge zu dem Scrollbar-Problem im Netz.

Was wieder mal meine Überzeugung verstärkt, dass der Opensource-Desktop unter Linux auf Dauer nicht zum Erfolg kommen wird, wenn bzgl. der Qualitätssicherung nicht ein deutlich höherer Standard erreicht wird. Das hier geschilderte Beispiel ließe sich ja um viele weitere Fälle aus der KDE-Geschichte ergänzen. Man denke nur an die Probleme bei der Einführung von Akonadi oder bestimmte Bugs in Kontact.

Ich meine, dass eine bessere Form der Qualitätssicherung wirklich notwendig ist, bevor laufend Verschlimmbesserungen von Opensoure-Programmen ihren Weg in die Repositories der Distributoren finden. Irgendwie scheint mir diesbezüglich ein wichtiges Glied zwischen der Entwicklungstätigkeit der Community und der Publikation der mit sehr hoher Frequenz entstehenden Opensource-Werke in den Repositories der Distributionen zu fehlen.

Hinzu kommt natürlich auch eine für meinen Geschmack zu hohe Frequenz, mit der regelmäßig an fundamentalen Bausteinen der Desktops selbst - speziell von KDE - gerüttelt wird. Der Desktop wird so möglicherweise zu einer unberechenbaren Größe für die Entwickler von Anwendungen. Das hatte ja zuletzt auch Miguel de Icaza zu Recht im Linux-Magazin kritisiert. Vielleicht ist der obige Fall ja auch ein Beleg für dieses Problem.

Ein Desktop lebt schließlich nicht allein von intrinsischer Innovation, sondern in gleichem Maße von den Applikationen, die darauf laufen müssen. Und deren Entwickler brauchen Zeit, um sich auf grundlegende Veränderungen der Desktop-Plattform einzustellen ....

Ein supermoderner Desktop ist nämlich wirklich wenig wert, wenn Applikationen, die vor einem halben Jahr veröffentlicht wurden, nicht mehr auf der neuen Desktopversion laufen.

OO 3.2.1.2 und KDE

Ich hatte ja versprochen, auch mal wieder was Positives zu schreiben ....

Kaum lässt man Frust ab (siehe den Beitrag von gestern zu Openoffice - "Ärgerliche Probleme der Openoffice Integration in KDE 4), passiert auch schon was. Spät am gestrigen Abend habe ich mir testweise die neueste verfügbare Openoffice-Version von Opensuses OO-"Unstable"-Repository installiert.

OpenOffice.org 3.2.1
OOO320m18 (Build:9502)
ooo-build 3.2.1.2

Nach ersten Tests so aus, als ob die gestern oben beschriebenen Probleme 1 und 2 behoben sind. Die KDE-Dialoge für Öffnen/Speichern kommen schnell und sind sofort bedienbar. Und die Statuszeile ist nun wieder permanent sichtbar und verschwindet nicht mehr bei Fensteränderungen oder Manipulationen am Text.

Nicht behoben ist allerdings der Punkt 3 : Die Checkboxen für die Toolbars werden beim Öffnen des Submenü-Dialogs immer noch mit falschen Flags angezeigt.

Aber: es tut sich was - was Positives ! Ich freue mich .....