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

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

(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

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.

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

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

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

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

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?

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