FS#46315 - [libreoffice-fresh] buggy/missing features due to GTK3 enabled and now on by default

Attached to Project: Arch Linux
Opened by Daniel (Dan39) - Wednesday, 16 September 2015, 16:31 GMT
Last edited by Andreas Radke (AndyRTR) - Saturday, 10 October 2015, 12:23 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 15
Private No


libreoffice-fresh a few months ago changed from having gtk3 only being used if you specifically wanted it to, to being used by default whenever it is built with it enabled and available. the support for gtk3 is incomplete, and there are some major features missing. in my personal experience i found that being able to move cells around with your mouse in Calc is not possible.

GTK3 is explicitly enabled in PKGBUILD. so yea, don't enable it.

This task depends upon

Closed by  Andreas Radke (AndyRTR)
Saturday, 10 October 2015, 12:23 GMT
Reason for closing:  Fixed
Additional comments about closing:  5.0.2-3 includes a install msg now about experimental gtk3 vcl and how to go with gtk2 vcl.
Comment by Andreas Radke (AndyRTR) - Wednesday, 16 September 2015, 18:38 GMT
You can still use gtk2, kde and generic vlc. Won't change it.
Comment by Sébastien Leblanc (sebleblanc) - Tuesday, 29 September 2015, 18:01 GMT
Upstream tells me in an IRC conversation that the feature should not be enabled:

<Me> Is the pivot table dialog broken in libreoffice 5.0.1 (fresh)? I cannot drag and drop fields into the boxes
<Me> This is on Linux
<erAck> sleblanc: let me guess, Arch Linux?
<Me> Indeed
<Me> erAck, did you need to know this?
<erAck> sleblanc: yes, because then the answer is easy; they enabled gtk3 despite that it is an experimental build option
<erAck> and drag&drop isn't implemented yet
<Me> Thanks for the explanation!
Comment by Andreas Radke (AndyRTR) - Tuesday, 29 September 2015, 18:38 GMT
LibO fresh branch is the version for brave people. I'm for keeping gtk3 vcl enabled. If not LibO devs will never receive enough feedback to get the vcl stable. Debian had a similar discussion. This is a checken-egg problem and because we are Arch I'm for the brave and risky way. Especially here where a safe fallback option is available.
Comment by Sébastien Leblanc (sebleblanc) - Tuesday, 29 September 2015, 22:56 GMT
Gah, for me it's a pain in the butt. I'm all in for promoting bleeding edge, not half-implemented features and stuff that upstream says should not be enabled.

Here is my experience as a long-time Arch Linux user:

- I upgrade to libreoffice-fresh, thinking I would get more performance/nice graphics/modern experience, whatever they are selling as new. So far so good.
- At some point, I realize I can't do pivot tables anymore. Maybe it is a window manager bug, since I am using Xmonad. Let's ask the Xmonad folks. I am told that I need to add workarounds to LO due to non-compliance with window manager standards. Applied the fixes, no improvements. But since my other computer running I3 is also affected, I want to ditch the idea that the WM is to blame.
- Installing libreoffice-still fixes the issue. Now that is some improvement.
- I ask around on LO, get told by a core LO dev (the guy itself who works on the Calc part) that the feature is not ready yet, despite the fact that Arch Linux enabled it. The only workaround is to disable the feature altogether.
- I search on the bug tracker for the issue. No results, despite the fact that it was already reported, because the issue was closed a while ago, and it does not show up in the results, by default. I open a new ticket.
- The ticket is marked as a duplicate and is closed minutes later. I reopen this bug instead, since I am very unsatisfied with the status quo.

The wiki mentions the workaround, but it is only listed under the Themes section, as a feature to make your LibreOffice integrate more nicely to your environment. It even says that GTK3 support is not enabled unless you tick the "Enable experimental features", which does not seem to affect VCL selection.

To me, it is not reasonable to penalize people who need the affected features in such a way. Furthermore, even if I set the default VCL to "gtk" on my system, it still means I will be stuck with the GTK2 version until the moment I realize that GTK3 support is finally deemed as ready.

If all this sounds like a rant, I am sincerely sorry.

Comment by Pablo Lezaeta (Jristz) - Tuesday, 06 October 2015, 22:26 GMT
Upstream has talked and gtk3 is not ready and not shall be enabled, unless arch want deviated from mainline enabling experimental features I think this need to be deactivated (the gtk3) until upstream say is complete or libreoffice enable it by default.
Comment by Friedrich Strohmaier (bitsfritz) - Thursday, 08 October 2015, 00:06 GMT
Had a crash simply by changing sheets while having marked two cells.

Steps to reproduce:
2. Select File-> new -> spreadsheet
3. Create one more sheet (sheet2)
4. Select b3-c3
5. change to sheet1
6. bang!

Brave might be nice, but serve crashing apps??

btw. Upstream has got Feedback
maybe enough to actually get stable in "stable"? :o))
Comment by Andreas Radke (AndyRTR) - Thursday, 08 October 2015, 16:46 GMT
Any idea how to include gtk3 vcl and not make it the default option?

I could make gtk2 the default one in /etc/profile.d/libreoffice-fresh.sh but this would break autodetection in kde.

I prefer the user to set the desired vcl and if default though experimental vcl is too buggy. One option is a post install msg with a warning
to set the vcl manually and last option is to disable gtk3. But it will be enabled by default in 5.1 anyways by default. Debian is shipping gtk3
again in their experimental tree.

Because the is a safe fallback option to go with gtk2 I'm still for keeping gtk3 for testing.
Comment by Friedrich Strohmaier (bitsfritz) - Friday, 09 October 2015, 14:28 GMT
> One option is a post install msg with a warning to set the vcl manually

This one would be of great help!
It helps every single archer with gtk-based environment not to stumble in the (already known) trap without warning.