For various reasons - all my own problems - I cannot build LO-25 with gtk, so qt6 it is. This worked wonderfully (thank you!) but the UI looks like a bad Motif fever dream reminiscent of the early 90s, and seems to ignore any settings made in qt6ct. Since I'm visually impaired this is .. not great. Searching the internets I found $URL (the official LO/QT6 announcement) which mentions the environment variable SAL_USE_VCLPLUGIN=qt6 to actually activate the qt6 backend; apparently it runs in some basic/backwards-compatible mode otherwise. Adding the setting to /etc/env.d/99libreoffice-theme fixes the problem, and LO looks just as it should. As we already install /etc/env.d/99libreoffice I was wondering if the setting should be part of the regular installation, since this is likely going to confuse quite a few people. Reproducible: Always Steps to Reproduce: 1. build LO-25 with USE="-gtk qt6" 2. do not enjoy ugly Motif-like UI flashback 3. export SAL_USE_VCLPLUGIN as described, enjoy beautiful L&F
In terms of adding a workaround in the ebuild, the question would be the semantics -- we would need to only do it with USE=qt6 (should possibly be USE=qt instead, but let's leave that for now) and not with USE="qt6 gtk". But what environment are you actually running LibreOffice in? Why is it not detecting that it should use qt6? Not only that, even if it thinks qt6 may not be preferable, why isn't it using anything over the grotty terrible fallback?
Thanks for the inquiry. I'm using xfce and the previous LO-24 looked fine, with both gtk/qt enabled, though I don't know which backend it actually picked (probably gtk3). Unfortunately it's already gone. I do have a few plain QT as well as KDE apps installed (kate, kdiff etc.), and they all pick up the settings from qt6ct to be in line with the desktop/gtk3 theme - all this has been working fine since forever, back then with qt5 and now with qt6. LO-25 is the new exception. It *might* be that this happens because I do not have USE=kde set - primarily because I didn't pay attention, but also because it's not really clear to me what that flag actually does. I understand that adding the environment might not be what everybody wants, and don't really know how to solve that. The environment settings are documented here: https://wiki.documentfoundation.org/Development/Environment_variables Unfortunately it doesn't say anything about precedence in case multiple backends are present, and I have not found anything in that regard. Maybe that's a hint and we should just not build both gtk & qt at the same time, and instead make them mutually exclusive? Then it would be clear which backend would need whatever setting. All that being said, I'm not complaining - LO-25 works fine, this was just a minor surprise and we have a simple nonintrusive fix. Maybe just an einfo is all we need to inform users about the possibility to select a backend?
ACK. What I'd like to do is find out from upstream what they *expect* to happen here and if we can improve the fallback without overriding their detection. Could you file a bug there (with screenshots too perhaps)?
(In reply to Sam James from comment #3) > ACK. What I'd like to do is find out from upstream what they *expect* to > happen here and if we can improve the fallback without overriding their > detection. Could you file a bug there (with screenshots too perhaps)? Sure, I'll try to do that in the next few days.
Nothing like a good treasure hunt :) A bit of spelunking revealed: https://cgit.freedesktop.org/libreoffice/core/tree/vcl/source/app/salplug.cxx#n314 which is a list of possible backends - obviously hardcoded, because dynamic discovery has not been invented yet. The generic, unthemed "gen" backend is listed after gtk*, but *before* qt*. My guess is that the backend plugins are blindly initialised in the given order, and so without explicit selection via env variable and in the absence of gtk I get "gen". The fix here is to reorder the list and put "gen" last, which I will obviously try first thing tomorrow, just out of spite.
Reading the code a bit further it turned out my hunch wrt. the plugin initialisation order was wrong; here is what actually happens. LO does a type of auto-detection of the desktop environment and then has a set of heuristics that it uses to determine which backend to activate. If that fails, it falls back to the generic (ugly) backend. In my case I successfully broke this mechanism: by using xfce as desktop (which would prefer a gtk backend) and not enabling gtk I got the generic backend. The same would probably happen with a qt-based desktop when building with "gtk -qt". Therefore setting the env var and explicitly picking a backend is the intended mechanism when autodisocvery is not working correctly or e.g. a distro wants to force a backend. It also means there's no bug to file. My suggestion is therefore: - +gtk +qt: do nothing & let LO decide basedon desktop environment. Maybe einfo about the LO web page on env variables, so that users can troubleshoot if necessary. - gtk OR qt: create the env var with the selected backend and einfo that we are forcing the selection - -gtk -qt6: not sure about headless mode That's all there is, really.
For what it's worth, I have the same issue, running a Cinnamon desktop (i.e. gtk) with both gtk and qt6 use flags enabled. I've tried recompling libreoffice with use flags +gtk -qt6 hoping to enforce gtk usage, but without success. The UI is still the old Motif-like version! Downgrading to libreoffice-24.2.7.2-r1 restores the UI to gtk.
(In reply to pste from comment #7) > For what it's worth, I have the same issue, running a Cinnamon desktop (i.e. > gtk) with both gtk and qt6 use flags enabled. I've tried recompling > libreoffice with use flags +gtk -qt6 hoping to enforce gtk usage, but > without success. The UI is still the old Motif-like version! > > Downgrading to libreoffice-24.2.7.2-r1 restores the UI to gtk. I was hoping that my explanation above cleared things up, but apparently not: disabling a backend does not enforce anything! It looks like Cinnamon is not recognised here: https://cgit.freedesktop.org/libreoffice/core/tree/vcl/source/app/salplug.cxx#n409 Try "export SAL_USE_VCLPLUGIN=gtk4" in a shell and run e.g. lowriter, that should help. No idea whether gtk4 will look like what you expected, but that's a different problem. :)
(In reply to Holger Hoffstätte from comment #6) > Therefore setting the env var and explicitly picking a backend is the > intended mechanism when autodisocvery is not working correctly or e.g. a > distro wants to force a backend. It also means there's no bug to file. > How do you conclude that? My suggestion was that in the event of heuristics failing, it should simply be trying available backends before ever using the fallback ugly one.
> Try "export SAL_USE_VCLPLUGIN=gtk4" in a shell and run e.g. lowriter, that > should help. No idea whether gtk4 will look like what you expected, but > that's a different problem. :) Well, this worked to some extent, but not satisfactory. Some things became more gtk-like (at a quick glance, I've not got time [yet] to investigate what aspects actually changed), but for example colors (gradients/shadows) became completely out of wack, so my guess is that the suggested use flag altered some but not all UI settings... I'll try to find time to report an upstream (cinnamon related) bug!
(In reply to pste from comment #10) > > Try "export SAL_USE_VCLPLUGIN=gtk4" in a shell and run e.g. lowriter, that > > should help. No idea whether gtk4 will look like what you expected, but > > that's a different problem. :) > > Well, this worked to some extent, but not satisfactory. Some things became > more gtk-like (at a quick glance, I've not got time [yet] to investigate > what aspects actually changed), but for example colors (gradients/shadows) > became completely out of wack, so my guess is that the suggested use flag > altered some but not all UI settings... > > I'll try to find time to report an upstream (cinnamon related) bug! It probably has nothing to do with Cinnamon but sounds like some general differences between gtk3 and gtk4, as reported in bug#950270 (see linked). If you have an overlay you could try to hack USE=gtk to mean gtk3 instead and see where that goes.
Created attachment 919916 [details, diff] Patch to add qt6 as VCL fallback for gtk-based environments After more spelunking and decyphering the ifdef-infested 90's-style C++ code this patch does the trick: I get the qt6 backend with the environment variable unset, i.e. the fallback works. Context: https://cgit.freedesktop.org/libreoffice/core/tree/vcl/source/app/salplug.cxx#n212 to 244 Two important learnings here: - the fallback to gtk3 which you asked for was disabled in the ebuild :-) - there was no fallback to qt6 so I added it So unless there are unsurmountable dependency hurdles we can: - consider turning USE=gtk back into gtk3/gtk4, which should fix the gtk fallback and also make #950270 happy - maybe add my qt6 emergency fallback as cherry on top for people with gtk-based desktops but USE="-gtk3 -gtk4 +qt6". That *might* even be something I could suggest upstream as it doesn't hurt the existing design.
What would happen if we disable the build of the "gen" backend? Would it then use the better/only one backend or crash?
(In reply to jospezial from comment #13) > What would happen if we disable the build of the "gen" backend? > Would it then use the better/only one backend or crash? That is not the problem we are discussing. Ending up with the gen backend means no other fallbacks were available. What is supposed to happen without that?
(In reply to Holger Hoffstätte from comment #12) > So unless there are unsurmountable dependency hurdles we can: > - consider turning USE=gtk back into gtk3/gtk4, which should fix the gtk > fallback and also make #950270 happy > - maybe add my qt6 emergency fallback as cherry on top for people with > gtk-based desktops but USE="-gtk3 -gtk4 +qt6". Those who care & dare can try my split-gtk ebuild at: https://github.com/hhoffstaette/portage/tree/master/app-office/libreoffice Defaults to gk3 but also allows gtk4/qt6 and has the qt6 fallback if no gtk backend is found in a gtk environment.
(In reply to Holger Hoffstätte from comment #2) > It *might* be that this happens because I do not have USE=kde set - > primarily because I didn't pay attention, but also because it's not really > clear to me what that flag actually does. KF6-based file dialog on top of Qt6, just in case you were still wondering.
(In reply to Holger Hoffstätte from comment #15) > > Those who care & dare can try my split-gtk ebuild at: > https://github.com/hhoffstaette/portage/tree/master/app-office/libreoffice > Well I care & dared (finally), and it works fine! ;) (except for a few minor UI-glitches that were present also in 24.2.7.2, cinnamon-related I believe, e.g. some bottom status bar icons not scaling ok) Great work! Does this imply feedback upstream, or just merging into portage? I mean, just to make next lo-update work as well (with gentoo repository)!
(In reply to pste from comment #17) > (In reply to Holger Hoffstätte from comment #15) > > > > Those who care & dare can try my split-gtk ebuild at: > > https://github.com/hhoffstaette/portage/tree/master/app-office/libreoffice > > > Well I care & dared (finally), and it works fine! ;) > (except for a few minor UI-glitches that were present also in 24.2.7.2, > cinnamon-related I believe, e.g. some bottom status bar icons not scaling ok) > > Great work! > > Does this imply feedback upstream, or just merging into portage? > I mean, just to make next lo-update work as well (with gentoo repository)! And, by the way, I forgot to specify. My cinnamon build is on gtk4 (no gtk3 installed at all), so that works as supposed!
(In reply to pste from comment #17) > (In reply to Holger Hoffstätte from comment #15) > > > > Those who care & dare can try my split-gtk ebuild at: > > https://github.com/hhoffstaette/portage/tree/master/app-office/libreoffice > > > Well I care & dared (finally), and it works fine! ;) Thanks :) > Does this imply feedback upstream, or just merging into portage? This is all our own problem. Happens. > I mean, just to make next lo-update work as well (with gentoo repository)! After some discussion on IRC I just opened a Github PR, so the next update to 25.2.1.2 should fix things.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ceac275be229f4e866cbfe8fbebdc5c518ae919e commit ceac275be229f4e866cbfe8fbebdc5c518ae919e Author: Holger Hoffstätte <holger@applied-asynchrony.com> AuthorDate: 2025-03-03 09:08:52 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-03-03 11:04:37 +0000 app-office/libreoffice: split USE=gtk back into gtk3/4 Commit 9c7f26240f9e unified the gtk USE flags, but it seems that was a bit premature since using only gtk4 still seems to cause many problems. Revert back to split use flags and enable gtk3 by default while still allowing gtk4 and qt6. Closes: https://bugs.gentoo.org/950170 Closes: https://bugs.gentoo.org/950270 Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com> Signed-off-by: Sam James <sam@gentoo.org> .../libreoffice/libreoffice-25.2.9999.ebuild | 28 ++++++++++++++-------- app-office/libreoffice/metadata.xml | 2 ++ 2 files changed, 20 insertions(+), 10 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a3c252c6a400b863dc4ae9f062a5589fe2638043 commit a3c252c6a400b863dc4ae9f062a5589fe2638043 Author: Holger Hoffstätte <holger@applied-asynchrony.com> AuthorDate: 2025-03-03 09:19:01 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-03-03 11:04:38 +0000 app-office/libreoffice: add qt6 as VCL backend fallback in gtk-based environments This will let LO properly fall back to qt6 in case neither gtk3/4 were built in. Bug: https://bugs.gentoo.org/950170 Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com> Signed-off-by: Sam James <sam@gentoo.org> .../files/libreoffice-25.2-vcl-backend-fallback.patch | 17 +++++++++++++++++ app-office/libreoffice/libreoffice-25.2.9999.ebuild | 4 ++++ 2 files changed, 21 insertions(+)
Holger and I discussed defaults (+gtk3 or not) and concluded that we should keep +gtk3 there for now (as otherwise one gets Qt 6 fallback); we may want to in a followup do some p.use finagling to allow moving that out of IUSE as a default.
