FS#45916 - [libreoffice-fresh] LibreOffice should still be using Gtk2 + HiDPi issues

Attached to Project: Arch Linux
Opened by Keith Curtis (KeithCu) - Friday, 07 August 2015, 03:53 GMT
Last edited by Andreas Radke (AndyRTR) - Saturday, 08 August 2015, 06:35 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

I'm running LibreOffice 5.0 and it appears to now be using the Gtk3 VCL plugin, which causes various problems such as screen redraw issues and HiDPI text looks bad. Here is a bug I filed about it: https://bugs.documentfoundation.org/show_bug.cgi?id=93184

From talking to various people in LibreOffice, it appears that the Gtk2 is still the recommended one.

Here is a quote from Tomaz Vajngerl:
--------
There was a gtk3 vcl plugin provided in previous LO versions in the same way as it is in 5.0 and this has not changed (except gtk3 is in a much much better state now). Just like before the gtk2 vcl plugin (if available) takes precedence over gtk3. In the official release there even is no gtk3 plugin.
--------

Can LibreOffice 5.0 go back to using Gtk2 like the old versions for a bit longer until the Gtk3 supports gets better?
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Saturday, 08 August 2015, 06:35 GMT
Reason for closing:  Won't fix
Additional comments about closing:  HiDPi fix will be included in the next upstream release.
Comment by Keith Curtis (KeithCu) - Friday, 07 August 2015, 04:54 GMT
I got another email from Tomaz later that says that LibreOffice uses Gtk3 on Gnome 3. I filed a bug asking them to go back to Gtk2 (https://bugs.documentfoundation.org/show_bug.cgi?id=93222), so maybe this is an upstream bug?
Comment by Keith Curtis (KeithCu) - Friday, 07 August 2015, 13:21 GMT
The upstream bug was resolved as notabug. Here was the comment put in there:
------------
Well, the official TDF build doesn't have gtk3 at all, and downstream users are free to do the same by passing --disable-gtk3 to the build script (or they can go the Debian/Ubuntu way of splitting the gtk3 support to a separate package). In case of Arch, not only it doesn't pass --disable-gtk3, it actually has an explicit --enable-gtk3. Also the end user has the freedom to not use the gtk3 plugin, even if present, by exporting SAL_USE_VCLPLUGIN=gtk.
Comment by Doug Newgard (Scimmia) - Friday, 07 August 2015, 13:29 GMT
Don't you love it when upstream just kicks the can down the road? It's their detection system that's defaulting to gtk3 even though it's not ready, but it's not their problem.

Edit: check out /etc/profile.d/libreoffice-fresh.sh
Comment by Sebastiaan Lokhorst (lonaowna) - Friday, 07 August 2015, 13:40 GMT
The upstream bug (about the HiDPI stuff) has been fixed, and will be in the next 5.0 release.

Besides that, I don't really see the problem with GTK3. It works fine on my system, and I can disable it with SAL_USE_VCLPLUGIN=gtk.
Comment by Keith Curtis (KeithCu) - Friday, 07 August 2015, 13:41 GMT
BTW, the one particular GTK3 bug I filed has been fixed, but I still see major repaint problems.
Comment by Andreas Radke (AndyRTR) - Friday, 07 August 2015, 14:01 GMT
Use /etc/profile.d/libreoffice-fresh.sh to preset your desired vcl. Arch is all about choice and the LibO-fresh branch is all about early adopting. I see not problem with upstream vcl detection. Feel free to change it to your needs if you want the a different look and feel.

There's nothing Arch needs to change in the way we package it.
Comment by Keith Curtis (KeithCu) - Friday, 07 August 2015, 14:15 GMT
Well, I see big repaint problems, but if I'm the only one, fixing it on just my machine is good enough.
Comment by Sebastiaan Lokhorst (lonaowna) - Friday, 07 August 2015, 14:23 GMT
But does "SAL_USE_VCLPLUGIN=gtk" work on your machine? Because I agree that, because GTK3 is still somewhat unstable, it should be possible to easily disable it. If that option does not work, I think that that's a problem. (To be clear: it works on my machine, but you previously said it doesn't on yours)
Comment by Keith Curtis (KeithCu) - Friday, 07 August 2015, 15:02 GMT
Yes, that environment variable fixes my problem. Thanks for the workaround. I see major screen redraw issues (on my HiDPI laptop). I'll type, and the text won't show up. I'll click on things in the dialog boxes and the content won't change.

If enough other people are also seeing big problems, it might be best to have Arch default to Gtk2. The code uses Gtk3 by default, but developers don't recommend it or deliver it in their binary builds.
Comment by Keith Curtis (KeithCu) - Friday, 07 August 2015, 15:17 GMT
BTW, I found out that they don't deliver it in their binary builds because they have a CentOS 5 machine which can't build Gtk3. So that fact isn't very relevant.
Comment by Andreas Radke (AndyRTR) - Friday, 07 August 2015, 17:01 GMT
The gtk2 fallback is working it seems. No need to change the default behavior.

About the HiDPi issue: Is this also solved with the gtk2 interface? I prefer to not pick random single commits from upstream if it's not a major issue. Next upstream release isn't far away and there's always the -still branch for serious use cases.
Comment by Keith Curtis (KeithCu) - Friday, 07 August 2015, 17:08 GMT
Yes, the HiDPI issue is solved with the Gtk2 interface.
Comment by Andreas Radke (AndyRTR) - Saturday, 08 August 2015, 06:34 GMT
Then I'm closing this one as "won't fix" following Arch way because there's a workaround and alternative pkg available. We'll wait for an upstream update. No backporting here.

Loading...