Added SAL_USE_VCLPLUGIN=qt5

[agaida]

The Qt5 plugin is really usable now and we should promote it. It's in the discretion of the distribution maintainers to make sure that it is installed.

[yan12125]

From https://bugs.documentfoundation.org/show_bug.cgi?id=123595#c7, an LibreOffice developer @michaelweghorn said:

I'd currently definitely not recommend using qt5 with native Qt rendering (i.e. without SAL_VCL_QT5_USE_CAIRO set in addition)

@michaelweghorn Is it still the case for the latest LibreOffice?

[michaelweghorn]

From https://bugs.documentfoundation.org/show_bug.cgi?id=123595#c7, an LibreOffice developer @michaelweghorn said:

I'd currently definitely not recommend using qt5 with native Qt rendering (i.e. without SAL_VCL_QT5_USE_CAIRO set in addition)

@michaelweghorn Is it still the case for the latest LibreOffice?

@yan12125 Yes, it's still the case, s. https://bugs.documentfoundation.org/show_bug.cgi?id=126272#c21 for some more details. Technically, it should mostly work as well as the "kde5" plugin when setting SAL_VCL_QT5_USE_CAIRO in addition, but that's nothing that upstream currently selects automatically or "supports" officially.

Bug reports for plain qt5 with the native Qt rendering path are welcome, but it's not really considered a priority right now and much more work. The main focus in the last months was getting the "kde5" (to be renamed to "kf5") VCL plugin ready (which is mostly qt5 with the Cairo rendering path plus kf5 file dialogs).

[agaida]

@michaelweghorn - not the outcome i hoped for, but meh :smile: - Ok, the plugin choice is downstream, pure Qt would be nice - so we should do nothing about right now.

With my package maintainer hat on: To be verbose about - there is nothing wrong with lo-kde5/kf5, it is really great in KDE, phantastic work, but it would introduce a bunch of dependencies like kio and kf5 components we would otherwise not use in LXQt. Given that we right now base our filemanagement onto libglib i think that we go better with lo-gtk3 right now.

[reneengelhard]

@michaelweghorn I remember that discussion from the ESC minutes for 6.2.x. But FWIW: "latest LibreOffice" here means 6.3 rc1. Does that problam exist there, too?

[michaelweghorn]

To add to/clarify my previous comment:

• LibreOffice has a mechanism to select a VCL plugin at runtime depending on the desktop environment in use, s. [1]. The plugins are tried in a specific order, depending on the desktop environment. For KDE Plasma and LXQt, that would be ["kde5", "gtk3_kde5", "gtk3", "gtk", "gen"]. The first one that can be loaded is used.
• A dlopen() is done on the plugin, i.e. if required libs are not installed, that will fail and the next plugin is used (so you should get gtk3 automaticallly on LXQt if kio libs aren't installed).
• That mechanism can be overriden by explicitly setting SAL_USE_VCLPLUGIN to the name of the plugin to use (e.g. qt5).
• IMHO, "kde5" plugin can be considered stable from LibreOffice 6.2.5/.6 on; I'm not aware of any major problems. (meta bug for kde5: [2])
• Just setting SAL_USE_VCLPLUGIN=qt5 will select qt5 plugin with the native Qt rendering path. This isn't ready for production use yet.
• By setting SAL_VCL_QT5_USE_CAIRO, you get the Cairo rendering path that is used for kde5 as well.
• Technically, "qt5" with SAL_VCL_QT5_USE_CAIRO set in addition should mostly behave as kde5. For some more details, s. Bugzilla comment by Jan-Marek referenced in my previous comment here, and the meta bug for native Qt rendering at [3].

Decision to leave plugin selection order "as is" for now was not explicitly for 6.2, so it's currently unchanged for 6.3 and master as well (relevant threads on mailing list e.g. [4] and [5]).

@agaida What distro is this? Does it ship LibreOffice as one large package that should only contain either gtk3 or qt5/kde5 VCL plugin? Debian e.g. has separate packages for the different plugins, which allows to install only what's wanted and thus decide at install/run time what VCL plugin is used (depending on desktop environment and installed VCL plugins).

@reneengelhard Does the above also answer your question? I'm not sure what you're referring to by "the problem", so might have missed the point you were asking about...

[1] https://gerrit.libreoffice.org/plugins/gitiles/core/+/master/vcl/source/app/salplug.cxx#144 [2] https://bugs.documentfoundation.org/show_bug.cgi?id=102495 [3] https://bugs.documentfoundation.org/showdependencytree.cgi?id=125943 [4] https://lists.freedesktop.org/archives/libreoffice/2019-May/082831.html [5] https://lists.freedesktop.org/archives/libreoffice/2019-May/082863.html

[agaida]

@michaelweghorn - it is debian.

 % apt show task-lxqt-desktop
Package: task-lxqt-desktop
Version: 3.53
Priority: optional
Section: tasks
Source: tasksel
Maintainer: Debian Install System Team <[email protected]>
Installed-Size: 6.144 B
Depends: tasksel (= 3.53), task-desktop, sddm, sddm-theme-debian-elarun | sddm-theme-debian-elarun, lxqt
Recommends: xsane, orca, libreoffice-gtk3, synaptic, libreoffice, libreoffice-help-en-us, mythes-en-us, hunspell-en-us, hyphen-en-us, system-config-printer
Download-Size: 1.052 B
APT-Sources: http://ftp.debian.org/debian stable/main amd64 Packages
Description: LXQt
 This task package is used to install the Debian desktop, featuring
 the LXQt desktop environment, and with other packages that Debian users
 expect to have available on the desktop.

So for the desktop task all things are fine for now. I maybe would prefer the Qt5 plugin if production ready. It was discussed in a different bug that our system dialog for file open will not work - so at least the native Qt dialog would be fine. But that's not important right now, GTK 3 is absolutly fine.

[michaelweghorn]

@agaida I see; it's not a coincidence that @reneengelhard and you are here at the same time. :)

With regard to the LXQt system file dialog: Is there a way to add custom widgets to that one? This is what LibreOffice does in order to add custom checkboxes etc. to the file dialog. This is also the reason why the so-called non-native (i.e. no platform/LXQt integration) dialog is currently used for the qt5 plugin everywhere except on KDE Plasma.

For KDE Plasma, we're currently using KFileWidget's KFileWidget::setCustomWidget API [1] to achieve this ([2]).

I just had a quick look at FileDialogHelper in libfm-qt [3] and QPlatformFileDialogHelper in qtbase, but didn't see anything there on how to do this. I guess, ideally, this would be possible in a platform-independent way (at least working for Qt-based platforms that can handle Qt widgets and layouts), but I couldn't figure out a way how to do this... An idea might be if 'QFileDialog::layout()' could return a QLayout provided by the platform integration, but as far as I can see, this is currently not possible. QFileDialog doc [4] explicitly says :

By default, a platform-native file dialog will be used if the platform has one. In that case, the widgets which would otherwise be used to construct the dialog will not be instantiated, so related accessors such as layout() and itemDelegate() will return null. You can set the DontUseNativeDialog option to ensure that the widget-based implementation will be used instead of the native dialog.

The latter (setting DontUseNativeDialog option) is what is currently done in LXQt case, so we can retrieve the layout using QFileDialog::layout() and set the custom controls there.

Any idea on how to do this for LXQt? (If there's no platform-independent way, that would mean adding a dependency to LXQt libraries, which might only be reasonable in yet another VCL plugin, or at least only if a specific build option is set, but maybe someone has a better idea...).

As you mentioned, there was already some previous discussion on this in some other GitHub issue: https://github.com/lxqt/lxqt/issues/1673 and LibreOffice Bugzilla issues referenced from there.

[1] https://api.kde.org/frameworks/kio/html/classKFileWidget.html#ace86a29da1c82ebdb54a8415d85cfbd7 [2] https://gerrit.libreoffice.org/plugins/gitiles/core/+/73b322a581b98a74c9d1868aca6d8ae05696697c/vcl/unx/kde5/KDE5FilePicker2.cxx [3] https://github.com/lxqt/libfm-qt/blob/master/src/filedialoghelper.h [4] https://doc.qt.io/qt-5/qfiledialog.html

[agaida]

It is a coincidence - ok, i asked @reneengelhard about the plugin things :D - with our dialog i guess @tsujan could help.

[tsujan]

We have had this discussion before (sorry, I don't have time to find it now):

With LXQt, the best choice is the default Qt file dialog; it isn't safe to add any widget to LXQt file dialog, IMHO.

As I said elsewhere, since I have a full KDE installation, I encounter no problem with LibreOffice under LXQt; it's decently styled by the active Qt widget style, while I don't set any EV:

What LXQt needs is the same dialog but without KDE dependency.

[michaelweghorn]

@tsujan Thanks for the quick reply!

With LXQt, the best choice is the default Qt file dialog; it isn't safe to add any widget to LXQt file dialog, IMHO. [...] What LXQt needs is the same dialog but without KDE dependency.

OK, so then there's nothing to do from LibreOffice side specifically for the LXQt file dialog at the moment. That same file dialog (non-native Qt file dialog, no KDE dependencies) is used for the plain qt5 VCL plugin (SAL_USE_VCLPLUGIN=qt5).

[tsujan]

@michaelweghorn Sorry, I didn't see that you'd added the link in your previous comment. You and I had the same opinion: https://github.com/lxqt/lxqt/issues/1673#issuecomment-471336807. In short: Use the default Qt file dialog outside KDE because there's no universal way of adding widgets to native Qt file dialogs.

[michaelweghorn]

@tsujan Alright, let's leave it as is then.

[stefonarch]

As qt5 is gone: closing