“SAL_USE_VCLPLUGIN=gen libreoffice” does not improve anything for me. The whole interface becomes kind of choppy.
With libreoffice-kf5 (coming with its 200 MiB of dependencies) + SAL_USE_VCLPLUGIN=kf5 things are just a little better compared to libreoffice-gtk3. Still lagging when scrolling.
I hope someone can suggest a better solution (if one exists).
On debian-12 I could also force skia sofware rendering in the libreoffice options (Tools → Options --View → below the option to disable hardware acceleration). Apart from removing the libreoffice-gtk3 package that improved performance as well.
I needed to enable font antialiasing though to make it bearable.
Just a heads up, running fresh new installed 4.2, with the new fedora templates.
Doubt this has anything to do with above tweaks but just experienced that adding a sheet/tab to my calc ods file and saving it a few times during updates resulted in today having lost all the work.
I usually >90% of the times don’t close the calc sheet and just shut down the AppVM, this was never a problem before and i explicitly remember having done a save after last changes.
This is a first for me in a decade of using LO.
The ods file only kept the changes right before i added the new tab/sheet to it.
Do you think this is related to the slowness of the GUI? Or a reproducible bug in LO?
i couldn’t say at this moment, just know that i saved a bunch of times and this has never happened before in all the years.
The only other thing that come to mind is the quit old nvme drive and/or some sync didn’t happen, which is also weird since i was working and saving for Hours in that sheet but Hours of work are lost.
Everything before i added that additional tab / sheet was saved though.
This sounds off-topic.
Data loss != slow scrolling
You really need to read my first post, especially the start of the second sentence.
To make you understand why i posted this here:
When changing something on a System and then suddenly observe odd behavior wouldn’t the place to post be where you picked the changes from?
You really need to read my first post, especially the start of the second sentence.
It says you doubt it is related to the tweaks above but it doesn’t clarify:
Without that info, I can’t relate the unfortunate data loss you experienced to the current topic.
Moderation note: edited inappropriate content away.
The steps i took:
sudo dnf remove libreoffice-gnome libreoffice-gtk3 && sudo dnf install libreoffice-kf5
sudo /etc/profile.d/libreoffice.sh
export SAL_USE_VCLPLUGIN=kf5
sudo nano /usr/bin/soffice
…
export SAL_USE_VCLPLUGIN=kf5
# oosplash does the rest: forcing pages in, javaldx etc. are
exec $RRCHECK $VALGRINDCHECK $STRACECHECK “$sd_prog/oosplash” “$@”
After this post i am unfortunately done replying to anything coming from you.
Hi everyone. Is there still only a temporary fix or why did the qubes os team not prioritize this bug and fixed within the last two years? Libreoffice is the most impotant software for me and it is still very slow.
Is this still considered the best solution at the moment? Making LibreOffice run at an acceptable speed under Qubes OS — Rudd-O.com
Thank you for qubes os! It is great to feel save, but this bug is really annoying.
As far as I understood this thread and especially this comment the issue is in LibreOffice itself and can therefore not be fixed in Qubes.
It is possible to mitigate the issue as described in various posts and the blog post you mentioned but as asked here and earlier here, at least for me it remains unclear if this really fixes all use-cases.
This is the solution for me too , on Deb12 and Fed41, Q4.2.4
It looks ugly but it allows to work, with LibreOffice again.
Update on the situation: I am currently in the process of installing a new Qubes OS installation from scratch (Qubes 4.2.4 on a certified NovaCustom laptop).
A minimal installation (default fedora-41-xfce template, sudo dnf install libreoffice) still shows the same near-unusable behavior when working with a pre-existing LibreOffice spreadsheet.
What I found while exploring the current state of LibreOffice fixes is that there is now both libreoffice-kf6 (a more recent version of the KDE LibreOffice integration) and libreoffice-gtk4. The latter is installed as a weak dependency together with the LibreOffice package, as well as the old and well-known libreoffice-gtk3, which causes the issue.
I found that the most minimal fix while keeping a reasonably nice-looking LibreOffice seems to be:
sudo dnf remove libreoffice-gtk3echo export SAL_USE_VCLPLUGIN=gtk4 (for some reason gtk4 is not picked up automatically).@taradiddles since you had put some serious effort into this issue, maybe you can help: In comment 59 you stated that you wanted to create a Qubes issue asking the fedora template maintainer to include the kf5 fix. I don’t know if you did something in this direction in the meantime, but since a clean LibreOffice installation doesn’t work I suppose that at least it wasn’t successful.
Shouldn’t it be pretty straight forward to adapt the Fedora package to switch to gtk4? Would this be something that should be conducted upstream as well?
I don’t really understand why libreoffice pulls both gtk3 and gtk4 as dependencies when it seems to still use gtk3 by default.
On a side note: The “Rudd-O fix” also works when using libreoffice-kf6 instead of the older kf5. However, as it pulls in more dependencies I guess the other one is preferable?
To answer my own question: As of today, the fix suggested by Rudd-O also applies to files opened from within the file explorer, at least in the now-default XFCE-based Fedora templates.
None of these fixes worked for me. Any ideas?