Arch Linux

You can still use gtk2, kde and generic vlc. Won't change it.

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!

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.

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.

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.

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??

Edit:
btw. Upstream has got Feedback
https://bugs.documentfoundation.org/show_bug.cgi?id=93054#c7
maybe enough to actually get stable in "stable"? :o))

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.

> 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.