Bei der derzeit aktuellen Version von LibreOffice (3.5.3.2 , DEB-Download direkt von der Projektseite) funktioniert bei mir auf einmal der MediaWiki-Export nicht mehr. Immer wenn ich auf Exportieren... → MediaWiki → Speichern klicke, erhalte ich die Fehlermeldung:
Fehler beim Speichern des Dokuments: Schreibproblem.
Die Datei konnte nicht geschrieben werden.
Auf dieser Seite habe ich die „Lösung“ für das Problem gefunden. Bei meiner Installation befindet sich die Datei allerdings unter /opt/libreoffice3.5/share/extensions/wiki-publisher/filter/odt2mediawiki.xsl. Dort muss der folgende Abschnitt auskommentiert werden (Zeile 800 ff.):
<!-- Formulas (Objects) > <include href="math/mmltex.xsl"/> <template match="math:math" priority="1"> <text><math></text> <apply-templates/> <text></math></text> </template-->
Nach dem Speichern funktioniert der Export auch wieder.
Wenn die Dokumentenwiederherstellung von LibreOffice ein Dokument nicht “retten” kann, läuft sie Amok. Das war bei OpenOffice.org schon so. Im verlinkten Beitrag beschreibe ich, dass die Datei Recovery.xcu gelöscht werden muss. Die hatte wenigstens noch einen sprechenden Namen und ich konnte mir so ungefähr ausmalen, wozu sie gut ist. Bei LibreOffice ist das leider nicht so einfach. Hier habe den Tipp, die Datei registrymodifications.xcu zu löschen. Bei meiner LibreOffice-Installation (Kubuntu mit aktuellen DEB-Paketen von der LibreOffice-Downloadseite) versteckt sich die Datei, anders als im verlinkten Post, unter ~/.config/libreoffice/3/user/registrymodifications.xcu.
Da ich mir nicht ganz sicher bin, wozu die Datei sonst noch dient, habe ich sie zunächst lediglich umbenannt. Anschließend kommt die Nachfrage zur Wiederherstellung nicht mehr. Sonstige negative Auswirkung habe ich –bisher– nicht verzeichnet.
Seit irgend einem Update in Precise Pangoline sahen meine GTK-Programme (LibreOffice, Firefox, GIMP etc.) einfach nur grottig aus. Anscheinend wurde der Stil oxygen-gtk nicht (mehr) erkannt. Nach ein bisschen trial-and–error mit den anderen in den Systemeinstellungen verfügbaren Stilen — die auch kein bisschen funktionieren wollten — und ein bisschen googlen, bin ich auf diesen Thread gestoßen. Wir dort beschrieben wird, habe ich das Paket xsettings-kde nachinstalliert und siehe da, die Darstellung funktioniert wieder.
Yeah — das Auge arbeitet schließlich mit
.
Seit meinem Update von Kubuntu 11.10 auf 12.04 versteht sich mein Google Chrome (und auch Chromium) nicht mehr mit meinem Proxy-Server. Die Proxy-Einstellungen habe ich in meiner .bashrc, in KDE´s Systemeinstellungen und auch separat in den Chrome-Einstellungen gesetzt und auch verschiedene Varianten durchgespielt. Ich habe sogar Chrome komplett gepurgt und einen neuen (Test–) User angelegt — nichts brachte einen Erfolg.
Die Document Foundation hat den ersten „Release Candidate“ von LibreOffice 3.5 freigegeben.
Der RC kann im Bereich für Testversionen auf libreoffice.de werden. Laut Ankündigung kann die neue Version neben einer bestehenden installiert werden. Das erfolgt im Verzeichnis /opt. Dort wird für jede Hauptversion jeweils ein Unterverzeichnis angelegt. Soweit funktioniert das auch.
Unter KDE SC muss ich, wie in den LibreOffice-Versionen zuvor, noch die Datei libstdc++.so.6 entfernen/umbenennen. Anderenfalls wird die grafische Oberfläche ziemlich hässlich dargestellt.
Meine Seite über die Installation habe ich entsprechend angepasst.
Da will ich endlich mal wieder etwas im Blog schreiben und muss feststellen, dass das Pentadactyl-Add-on dies verhindert.
Derzeitige Abhilfe: Deaktivieren der Erweiterung. Den Bug habe ich auch schon gemeldet.
Update (23.01.2012)
Im Kommentar auf meine Fehlermeldung wird beschrieben, dass man mit STRG+z den “Pass-Through-Modus” aktivieren kann. Damit werden die Tastenkombinationen quasi deaktiviert und das Arbeiten im WordPress-Editor wieder möglich. Zum Verlassen muss man dann ESC drücken. Das funktioniert soweit zwar, allerdings muss man aufpassen, dass man auch immer daran denkt
.
Hoffentlich wird der Bug dann in (einer) der nächsten Version von Pentadactyl beseitigt.
In diesem Artikel beschreibe ich, wie ich die Programme in meinem Autostart dezimiere. Dem fällt auch das Applet des Netzwerkmanagers zum Opfer. Daher habe ich mir ein kleines Script geschrieben. Dieses setzt den jeweiligen Status meiner Wlan-Karte und des Applets zurück. Das heißt, wenn sie aktiviert sind, werden sie deaktiviert und umgekehrt. Das Script kann ich entweder per Terminal oder via angelegtem Starter aufrufen.
Seit ein paar Wochen habe ich Ubuntu, respektive Unity, auf meinem Samsung NC10 installiert. Nach einer Weile habe ich mich mit dem unity-eigenen Bedienkonzept angefreundet. Nun finde ich es eigentlich richtig gut, zumindest aber einen Schritt in die richtige Richtung – für mobile Endgeräte, wohlgemerkt.
Eines hat mich allerdings gestört:
Wenn schon Facebook-Chat dann wenigstens mit einem vernünftigen Client und nicht per Browser, oder? Denkste!
Seit geraumer Zeit fällt mir auf, dass meine Nachrichten via Kopete entweder nicht bei der Gegenstelle ankommen oder neue Nachrichten nicht in Kopete angezeigt werden. Klar, dass so etwas im Chat zu Verwirrungen, gar Unstimmigkeiten, führen kann
.
Zunächst schob ich den Fehler auf Kopete, der ja nicht mehr wirklich taufrisch ist. Nachdem ich mein Netbook mit Ubuntu bestückt habe und darauf Pidgin nutze, tritt hier der Fehler aber ebenso auf. Entsprechende Bugreports bescheinigen, dass ich nicht der Einzige mit dem Problem bin. Scheinbar hat Facebook im Oktober etwas an der Chat-API geändert, was nun zu diesen Fehlern führt.
Nun habe Empathy im Test und werde mal prüfen, ob das Verhalten auch hier reproduzierbar ist.
Schade, wenn Facebook schon XMPP/Jabber einsetzt, sollte dies auch normal in entsprechenden Clients nutzbar sein. Die zeigen dann natürlich keine für Facebook Früchte tragende Werbung an. ![]()
Ich habe mir heute den Korrektor erneut gekauft. Die massive Kritik scheint erfolgreich gewesen zu sein. Auf der Downloadseite ist nun deutlich von der 32-Bit-Linuxversion die Rede. Auch die Pakete sind neu gepackt und die Dateinamen enthalten keine Umlaute mehr. Warum nicht gleich so
.
Nach wie vor lässt sich der Hersteller nicht zu einer 64-Bit-Version seines Produktes aus. Weder auf der Homepage, noch als bzw. in der Antwort auf meine direkte (Nach-) Frage.
Mit einigem Gefrickel ist es aber möglich, den Korrektor auch auf dem 64-Bit-Ubuntu zum Laufen zu bringen. Das hat ein User hier im Duden-Korrektor-Thread auf ubuntuusers.de beschrieben.
Zusammengefasst lautet der Tipp dort in etwa so:
LibreOffice muss in der 32-Bit-Version heruntergeladen und installiert werden. Anschließend muss die Java-JRE zugewiesen werden, natürlich auch in der 32-Bit-Version. Diese habe ich mir direkt von der Oracle-Seite geladen und nach /opt entpackt. In den LibreOffice-Optionen weise ich diese dann zu. Danach müssen noch einige Bibliotheken verbogen verlinkt werden:
echo /opt/libreoffice3.4/ure/lib | tee /etc/ld.so.conf.d/i386-libeoffice-ure.conf sudo ldconfig
Zuerst wird eine Konfigurationsdatei erstellt (tee /etc/ld.so.conf.d/i386-libeoffice-ure.conf), die auf die installierten LibreOffice-Bibliotheken (echo /opt/libreoffice3.4/ure/lib) verweist. Dabei muss man darauf achten, dass auf die richtige Libreoffice-Version verwiesen wird, in diesem Fall libreoffice3.4. Der zweite Befehl stellt sie dem System zur Verfügung.
Bei mir läuft das Duo nun in dieser Konstellation, obwohl subjektiv die Performance, grade beim LO-Start, leidet.