Opensuse Leap 15.4 on a PC – II – Plasma, Gnome, flatpak, Libreoffice and others on (X)Wayland?

In the last post of this series

Upgrade to Opensuse Leap 15.4 – I – a look at repositories, Nvidia, Vmware WS, KVM, Plasma widgets

we saw that an upgrade from Leap Opensuse 15.3 to Leap 15.4 is a relatively smooth operation. After the basic upgrade I wanted to look a bit at an interesting detail – namely (X)Wayland. And got surprised – positively and negatively. This post summarizes some of my experiences.

Nvidia and Wayland

For a long time it was almost impossible to use Wayland in combination with Nvidia and KDE. Which mostly was the fault of Nvidia. See an Heise article on this topic here. See also the experience of a Gnome user here – although I do not share his bad experience with a X11-based KDE Plasma on Nvidia. For years I have not seen a realistic chance for a productive use of Wayland on my PCs and laptops with Nvidia-cards. KDE PLasma did not work at all on Wayland. Also with Gnome I experienced terrible difficulties. But Nvidia has improved its support for Wayland significantly in 2022, starting with driver version 470. For Nvidia driver version 525 we would expect some stability.

Continue reading

Libreoffice 6.0 und 6.1 Draw unter KDE/Plasma und Gnome – mit gtk3-Unterbau viel zu langsam

Einer meiner treuen Begleiter war Libreoffice Draw. Aber nach dem Upgrade auf Opensuse Leap 15 hatte ich damit beim Arbeiten mehr Frust als Lust. Ich muss z.Z. Skizzen einer Art neuronaler Netzwerke erstellen. Da kommen mal schnell 50 bis zu über hundert Einzelobjekte zusammen, die in großer Anzahl durch “Verbinder” aneinander gekoppelt werden müssen.

Das aktuelle Draw der Libreoffice Versionen 6.0 und 6.1 ist unter einem KDE-System mit GTK3 dafür aber viel zu langsam:

Klickt man auf das Symbol für “Verbinder” in der Leiste für Zeichnungstools, so dauert es auf hochauflösenden Schirmen (2K bis 4K) und bei komplexen Zeichnungen zwischen 4,5 und 8 Sekunden, bis die Zeichnung auf eine Darstellung mit allen Connector-Punkten der Objekte wechselt.

Ich habe nun wahrlich kein langsames System; auch die Speichereinstellungen für LO habe ich bereits (mühsam; s.u.) nach oben gesetzt. Während des Darstellungswechsels für Verbinder geht die Belastung des genau einen CPU-Kerns, den LibreOffice leider nur nutzt, kurzzeitig auf 100%.

Bei einer normalen “LO 6”-ImplementierungInstallation ist das Paket “libreoffice-gtk3” installiert; GTK3 wird dann automatisch gezogen. Ein gezielter Start für GTK3 ist im Terminal mit “SAL_USE_VCLPLUGIN=gtk3_kde5 libreoffice &” möglich. Nun kann man sich zusätzlich das Paket “libreoffice-gtk2” installieren und den Aufruf zu “SAL_USE_VCLPLUGIN=gtk_kde5” abändern.

Ein nachfolgender Test zeigt, dass die Zeiten beim Einsatz von GTK2 im Bereich von 2-3 Sek. liegen! Damit kann ich gerade noch leben. Weitere Tests offenbaren Folgendes:

Die Geschwindigkeit, mit der Draw die Anzeige von Connector-Punkten aller Objekte auf den Schirm bringt, hängt vom Zoomfaktor ab, mit der man sich das odg-Dokument anzeigen lässt; kleine und große Zoom-Faktoren machen den Umgang mit Verbindern bisweilen deutlich schneller.

Wer also große Diagramme mit vielen Objekten und Verbindern zeichnen will, sollte im Umgang mit Libreoffice 6.1 auf GTK3 verzichten. Zumindest unter KDE. Das kann man dort entweder durch den Aufruf

SAL_USE_VCLPLUGIN=gtk_kde5 libreoffice &

erreichen, oder aber indem man das Paket libreoffice-gtk3 deinstalliert und dafür das Paket “libreoffice-gtk2” installiert (neben libreoffice-qt5). Ein Verzicht auf gtk2 und gtk3 sowie eine alleinige Installation von libreoffice-qt5 führt vom Layout her übrigens in die GUI-Steinzeit. Ob das so richtig ist, mag ich im Moment nicht einmal recherchieren.

Nun habe ich auch das Rendern über OpenGL ausprobiert – funktioniert leider nicht => Schwarze Menüs. Ansonsten wäre der Aufbau der Zeichnung selbst etwas schneller …
Tests unter Gnome und LXDE brachten leider die gleichen Ergebnisse.

Ich hoffe auf Updates – und darauf, dass sich die LO-Entwickler endlich mal Gedanken darüber machen, an welchen Stellen sich Multithreading lohnen würde. Der Umgang mit Verbindern wäre da ein erstes gutes Betätigungsfeld. So wie der Stand im Moment im Zusammenspiel von Draw mit GTK3 aussieht, sind LO 6.0 und 6.1 jedenfalls eine Enttäuschung.

P.S. zum Thema Menü-Änderungen: Hinzu kommt der sich auch unter Kontact/Kmail ausbreitende Ehrgeiz von Maintainern, bewährte Menüpunkte für Programm-Einstellungen, die die Performance und die RAM-Nutzung einer Applikation beeinflussen, aus dem normalen Menübereich in eine völlig unübersichtliche und undokumentierte globale Parameter-Konfiguration zu verbannen. So geschehen bei Kmail; so geschehen bei LO.

Liebe Leute: Seit wann bieten wir dem User unter Linux weniger Optionen an?
Und seit wann wird Bewährtes und Verständliches in der Menüstruktur zugunsten unverständlicher und undokumentierter Parameter-Kaskaden aufgegeben? Bitte liebe LibreOffice-Teams: Hört mit diesem falschen Ehrgeiz an Options-Verlagerung und -Vernichtung auf … und kümmert euch lieber mal um die Performance.

Nachtrag 19.10.2018 zur Performance: Es ist inzwischen insgesamt ein wenig besser geworden (LO 6.1.3); dennoch geht das Arbeiten mit Verbindern in DRAW unter GTK2 immer noch schneller von der Hand als unter GTK3.

 

Libreoffice 6.0 unter Opensuse Leap 15 KDE/ Plasma – GTK3-Stil “Breeze” macht Probleme

LO ist eine GTK-Anwendung und nutzt in der Version 6.x GTK3. Wie ich kürzlich beschrieben habe, wollte ich u.a. Breeze als GTK3-Stil für GTK-Anwendungen unter Opensuse Leap 15.0 mit KDE/Plasma nutzen. Ursprünglicher Grund war die Suche einer verbesserten, kontrastreichen Darstellung von SWT-Bedienelementen unter Eclipse Photon mit Dark Scheme.

Leider musste ich heute feststellen, dass – zumindest bei mir – der Einsatz von Breeze als GTK3 Style mit der aktuelle Version 6.1.1 von LO zu Problemen führt: Der Scrollbar funktioniert nicht oder nicht immer zuverlässig. Keine Ahnung, was Ursache dieses Breeze-spezifischen Problems ist.

Wer also ein funktionierendes LO 6.1.1 unter KDE/Plasma haben will, sollte also z.B. auf “Adwaita” oder “Ambience” als GTK3-Style ausweichen. Beide Styles funktionieren im Gegensatz zu “Default” auch sehr gut mit dem Dark Scheme Eclipse Photon.