Bug Hunting Session
Bug 123595 - Do not default to KDE5 VCL plugins under LXQt
Summary: Do not default to KDE5 VCL plugins under LXQt
Status: RESOLVED DUPLICATE of bug 122752
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.2.0.3 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: KDE
  Show dependency treegraph
 
Reported: 2019-02-20 15:41 UTC by Chih-Hsuan Yen
Modified: 2019-04-08 09:13 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chih-Hsuan Yen 2019-02-20 15:41:35 UTC
Description:
Also reported in https://github.com/lxqt/lxqt/issues/1673

Currently, LibreOffice tries KDE5 and similar VCL plugins if LXQt desktop environment is detected: https://cgit.freedesktop.org/libreoffice/core/tree/vcl/source/app/salplug.cxx#n188.

This behavior can cause problems. With SAL_USE_VCLPLUGIN=kde5 or gtk3_kde5, hitting Ctrl+O makes LibreOffice hang. Meanwhile, there's an error message in the terminal:

/usr/lib/libreoffice/program/lo_kde5filepicker: error while loading shared libraries: libKF5KIOFileWidgets.so.5: cannot open shared object file: No such file or directory

LXQt != KDE. Specifically, kio is not expected to be installed before using LXQt. I suggest using pStandardFallbackList if LXQt is detected.

Steps to Reproduce:
1. Install LXQt WITHOUT kio 
2. Unset all SAL_USE_VCLPLUGIN environment variables
3. Run LibreOffice
4. Hitting Ctrl+O

Actual Results:
The open file dialog appears

Expected Results:
LibreOffice hangs, waiting for the open file dialog.


Reproducible: Always


User Profile Reset: No



Additional Info:
Environment: Arch Linux x86_64 up-to-date
Comment 1 Michael Weghorn 2019-02-21 08:21:05 UTC
The issue with the file picker that you're describing should already be fixed in LibreOffice 6.2.1 by these commits:

https://gerrit.libreoffice.org/plugins/gitiles/core/+/71562327d4f4d9d46b129fbb41184f21116ba78d%5E%21
https://gerrit.libreoffice.org/plugins/gitiles/core/+/9455565fba299645372ddf432d25b679af51281f%5E%21

With those commits in place, a plain (non-native) Qt file picker is used on LXQt, thus not requiring KIO to be installed.

If you still think that LXQt should default to another VCL plugin than kde5, please open a separate issue. I personally have no strong opinion on that, but note that I'd currently not recommend using the plain "qt5" VCL plugin, since this one is quite a bit from being usable for daily use in my opinion.
Please also see bug 122752 for more details, in particular bug 122752 comment 25.

*** This bug has been marked as a duplicate of bug 122752 ***
Comment 2 Chih-Hsuan Yen 2019-02-22 15:16:11 UTC
Hi Michael Weghorn!

Thank you very much for looking into my bug report and point me potential fixes!

Following your last comment, I downloaded and built LibreOffice 6.2.1 [1] with a modified version of Arch Linux's packaging script [2]. The result is out of my expectation :D

/usr/lib/libreoffice/program/libvclplug_kde5lo.so now links to libKF5KIOFileWidgets.so.5 according to the output of `readelf -d`. As a result, `SAL_USE_VCLPLUGIN=kde5 libreoffice` does not load the KDE5 VCL plugin under LXQt (kio uninstalled). Instead, libreoffice loads gtk3_kde5.

I guess I need open another bug report? Official 6.2.1 testing DEBs [2] appears to come with the same problem (the KDE5 VCL plugin requires KIO) according to output of `readelf -d`.

Best Regards,

Chih-Hsuan Yen


[1] https://download.documentfoundation.org/libreoffice/src/6.2.1/libreoffice-6.2.1.1.tar.xz
[2] https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/libreoffice-fresh
[3] https://donate.libreoffice.org/home/dl/deb-x86_64/6.2.1/zh-TW/LibreOffice_6.2.1.1_Linux_x86-64_deb.tar.gz
Comment 3 Michael Weghorn 2019-02-23 09:51:22 UTC
(In reply to Chih-Hsuan Yen from comment #2)
> Following your last comment, I downloaded and built LibreOffice 6.2.1 [1]
> with a modified version of Arch Linux's packaging script [2]. The result is
> out of my expectation :D

Thanks for testing!

> /usr/lib/libreoffice/program/libvclplug_kde5lo.so now links to
> libKF5KIOFileWidgets.so.5 according to the output of `readelf -d`. As a
> result, `SAL_USE_VCLPLUGIN=kde5 libreoffice` does not load the KDE5 VCL
> plugin under LXQt (kio uninstalled). Instead, libreoffice loads gtk3_kde5.

Oh...

Did that actually just start with the new LibreOffice version 6.2.1 and was not the case with the earlier version 6.2.0.3 that this bug report was initially created against? I'm not aware of any relevant change that may have changed that, but if that actually changed, one might have a look at what was the cause for this.

Is there any problem with installing the linked kio libraries for this scenario (even though they're not used at run time)?
If needed, I'd usually expect that distro packages whould have it as a dependency, and e.g. Debian packages behave that way [1], so the problem you describe wouldn't occur there.
Like the name suggests, the "kde5" VCL plugin is primarily targeted at providing good integration into kde5, so without further knowledge, I'm not sure whether it's actually a bug it requires kf5 libraries. But I totally see your point it's somewhat unfortunate they're required when they're not even used at run time.

Do you have an idea on how to solve this? I'm not really familiar with what options you might use to influence linking or any other aspect in a way to properly address this.


[1] https://packages.debian.org/experimental/libreoffice-kde5
Comment 4 Chih-Hsuan Yen 2019-03-07 11:00:47 UTC
Sorry for the late response, I was busy on other projects the past two weeks.

> Did that actually just start with the new LibreOffice version 6.2.1 and was not the case with the earlier version 6.2.0.3 that this bug report was initially created against? I'm not aware of any relevant change that may have changed that, but if that actually changed, one might have a look at what was the cause for this.

You're right. It's not a regression but an issue in both 6.2.0.3 and 6.2.1. In both versions /usr/lib/libreoffice/program/libvclplug_kde5lo.so links to libKF5KIOFileWidgets.so.5, and I got errors when opening or saving files.

> Is there any problem with installing the linked kio libraries for this scenario (even though they're not used at run time)?

It's fine to install them for myself, but maybe not for others. As a LXQt developer, I need to make sure the default configuration of LibreOffice works fine for almost all LXQt users.

> If needed, I'd usually expect that distro packages whould have it as a dependency, and e.g. Debian packages behave that way [1], so the problem you describe wouldn't occur there.
> Like the name suggests, the "kde5" VCL plugin is primarily targeted at providing good integration into kde5, so without further knowledge, I'm not sure whether it's actually a bug it requires kf5 libraries. But I totally see your point it's somewhat unfortunate they're required when they're not even used at run time.

The packaging philosophy of Arch Linux is somewhat different the Debian one. On Arch Linux, there's only one `libreoffice-fresh` package, which includes the kde5 VCL plugin as it's enabled at the compile time, and `kio` is just an optional dependency as it's not required to run libreoffice on other desktop environments. I don't think Arch Linux maintainers will move `kio` into mandatory dependencies if they don't want complaints from users of GNOME or MATE.
Comment 5 Michael Weghorn 2019-03-07 17:51:30 UTC
OK, thanks for the update.

(In reply to Chih-Hsuan Yen from comment #4)
> The packaging philosophy of Arch Linux is somewhat different the Debian one.
> On Arch Linux, there's only one `libreoffice-fresh` package, which includes
> the kde5 VCL plugin as it's enabled at the compile time, and `kio` is just
> an optional dependency as it's not required to run libreoffice on other
> desktop environments. I don't think Arch Linux maintainers will move `kio`
> into mandatory dependencies if they don't want complaints from users of
> GNOME or MATE.

I understand. In my understanding, this basically seems to work as designed then. If you have the required packages installed, you'll get the kde5 VCL plugin, otherwise you get another one (according to the fallback list, which currently is the same one as for Plasma -- not sure whether it would make sense to use another one).

As mentioned earlier, I understand it's a little unfortunate since the kio libraries are not needed at run time for non-Plasma desktops, so if you have any good idea on how to properly address this in LibreOffice, I'll be happy about that one.

Otherwise it seems to me like the only way to deal with it for now is that it's up to the users/admins to install the required packages if they want to use kde5.
Does that make sense?

Maybe, the qt5 VCL plugin might be an alternative when the "SAL_VCL_QT5_USE_CAIRO=true" environment variable is set in addition, but I can't really tell how well this works (i.e. setting "SAL_VCL_QT5_USE_CAIRO=true" and "SAL_USE_VCLPLUGIN=qt5" via the distro).
Comment 6 Chih-Hsuan Yen 2019-03-09 18:01:58 UTC
> if you have any good idea on how to properly address this in LibreOffice, I'll be happy about that one.

Not trying KDE/Qt plugins at all appears to be the simplest solution. No more worries about extra environment variables and additional packages. That is, use pStandardFallbackList instead of pKDEFallbackList for DESKTOP_LXQT in vcl/source/app/salplug.cxx.

> Otherwise it seems to me like the only way to deal with it for now is that it's up to the users/admins to install the required packages if they want to use kde5.
> Does that make sense?

If a VCL plugin requires extra packages to work, it's better to not make it as the default IMO. Users who want it can just specify SAL_USE_VCLPLUGIN.

> Maybe, the qt5 VCL plugin might be an alternative when the "SAL_VCL_QT5_USE_CAIRO=true" environment variable is set in addition, but I can't really tell how well this works (i.e. setting "SAL_VCL_QT5_USE_CAIRO=true" and "SAL_USE_VCLPLUGIN=qt5" via the distro).

That's also an option. We (LXQt developers) can add default environment variables  in lxqt-session. In a previous comment you said the qt5 VCL plugin is not recommended for daily use. Is the combination SAL_VCL_QT5_USE_CAIRO=true SAL_USE_VCLPLUGIN=qt5 considered stable enough for daily use?
Comment 7 Michael Weghorn 2019-03-09 22:11:12 UTC
(In reply to Chih-Hsuan Yen from comment #6)
> Not trying KDE/Qt plugins at all appears to be the simplest solution. No
> more worries about extra environment variables and additional packages. That
> is, use pStandardFallbackList instead of pKDEFallbackList for DESKTOP_LXQT
> in vcl/source/app/salplug.cxx.

As mentioned earlier, I don't have a strong opinion on this, so feel free to open a new bug report requesting this if you think this is the way to go - and then I think it's best to have the UX team decide upon it.

For reference, at a quick glance the current handling of LXQt was introduced by this commit:

commit ac9c14dbbd3a4341de0aa1b1dbc37ad2ce69398c
Author: Simon Quigley <tsimonq2@ubuntu.com>
Date:   Wed Oct 10 21:16:17 2018 -0500

    Add support for LXQt as a Linux desktop environment.
    
    This change makes LXQt use the Breeze icon theme, and adds it as a
    desktop environment along the other supported DEs.


> If a VCL plugin requires extra packages to work, it's better to not make it
> as the default IMO. Users who want it can just specify SAL_USE_VCLPLUGIN.

Well, strictly speaking, basically all VCL plugins require extra packages in some way, e.g. gtk will require gtk2 packages, gtk3 will require gtk3 to be installed, etc. (though those packages will be present on many systems anyway). In my opinion, it's fine to use a different default e.g. on KDE Plasma than on GNOME.

> That's also an option. We (LXQt developers) can add default environment
> variables  in lxqt-session. In a previous comment you said the qt5 VCL
> plugin is not recommended for daily use. Is the combination
> SAL_VCL_QT5_USE_CAIRO=true SAL_USE_VCLPLUGIN=qt5 considered stable enough
> for daily use?

To be honest, I don't know. To my knowledge, the qt5 VCL plugin is currently mainly meant to be used as the foundation for the kde5 one. I'd currently definitely not recommend using qt5 with native Qt rendering (i.e. without SAL_VCL_QT5_USE_CAIRO set in addition), but I don't know how well it works with Cairo rendering. This MIGHT be close to the kde5 VCL plugin, but you'd probably need to do some testing to find out more...
Comment 8 Chih-Hsuan Yen 2019-03-10 06:17:41 UTC
> For reference, at a quick glance the current handling of LXQt was introduced by this commit:

Oops, the commit author is also an LXQt developer. Will discuss this in LXQt first before opening new issues...
Comment 9 Chih-Hsuan Yen 2019-04-08 03:22:27 UTC
Hi Michael Weghorn,

We reached a conclusion in LXQt, and I created https://bugs.documentfoundation.org/show_bug.cgi?id=124598. Could you have a look at the new ticket?
Comment 10 Michael Weghorn 2019-04-08 09:13:25 UTC
(In reply to Chih-Hsuan Yen from comment #9)
> Hi Michael Weghorn,
> 
> We reached a conclusion in LXQt, and I created
> https://bugs.documentfoundation.org/show_bug.cgi?id=124598. Could you have a
> look at the new ticket?

Hi Chih-Hsuan Yen,

yes, I'll take a look.