Please add back the gtk3 USE flag! * I'm using XFCE, hence my system is gtk3 only, there is no gtk4 application installed, and I'm using a very specialized theme (all colors completely redefined) which contains only gtk3 settings and no gtk4 settings. So if I start LO without SAL_USE_VCLPLUGIN set, I seem to get the general X11 backend which looks very strange and primitive, does not follow the theme colors, and most important, has all UI fonts so small that menus and dialogs are practically unreadable and unuseable (I've a very high-res screen). If I install gtk4 libs and start with SAL_USE_VCLPLUGIN=gtk4, the font size is fine, but the theme and most important the color settings are still missing (because my system theme does not support gtk4), and most important, all the dialogs feel completely alien and are very hard to use: XFCE and all other apps use classical GTK2/GTK3 dialog layout (I use XFCE and a theme without client side title bars) with buttons at the bottom and so on, but LO with gtk4 uses a completely different dialog layout with a very strange button placement, which is practically almost unuseable if one has been used to classical gtk for 20 years (dialog buttons in the dialog title bar?!? Cancel button at the top-left corner?!?). Moreover, some dialogs immediately crash in gtk4 (e.g. "export PDF"), but work fine in X11 mode. Reproducible: Always
Does that mean XFCE has no GTK4 integration?
XFCE does not require gtk4 and does not depend on it, I could install XFCE and all of its applications without installing gtk4. XFCE ist strictly gtk3, and I'm not aware of any plans to switch to gtk4. I think XFCE would loose many of its users if XFCE switched to gtk4, many people use XFCE because they want to avoid gtk4 (or don't want to spend the ressources for gtk4, many years ago there was a massive discussion against XFCE switching from gtk2 to gtk3 because of the increased ressource consumption: XFCE is the desktion for small and very small systems). Most likely, I would switch to KDE if XFCE became gtk4. The XFCE settings app allows to switch between existing themes in /usr/share/themes, but XFCE does not offer any themes or styles of its own: It uses whatever the user installs and selects. That could be one of the standard gtk3 themes, but could also be any other gtk3 theme. Of course the theme might also contain gtk4 theme definitions, but XFCE does not require them and is completely gtk4 ignorant. I use a locally modified variant of Zen https://github.com/takinoy/zen-gtk-themes, because it contains extra definitions for XFCE and still perfectly works and looks fine with gtk2, gtk3 and XFCE. I think many XFCE users still use one of the themes distributed with the mate desktop years ago, because those looked quite nice and were well supported at that time. But as far as I know, even today none of the mate themes support gtk4 (and most likely never will, I think mate is also strictly gtk3 and has decided to never switch to gtk4), and the Zen theme will also never have gtk4 support.
First of all, as I wrote above, the gtk4 backend reproducibly crashed LO for me when opening the "export PDF" dialog. Secondly, there is some strange technical problem with the gtk4 backend (or in fact with any backend except default X11): I need to set SAL_USE_VCLPLUGIN explicitly. This was *not* necessary with LO 24 and gtk3. I had LO compiled with gtk4, and I had installed gtk4 for it, but without SAL_USE_VCLPLUGIN, LO still came up with the X11 backend. I now have LO compiled with the qt6 backend, and I have qt6 installed, but again without SAL_USE_VCLPLUGIN, LO still comes up with the X11 backend. (besides that, qt6 is much better than gtk4 and did not crash so far, but it is still worse than gtk3: It has some minor visual bugs, and one of them makes it really hard to use). To fix that, I've set SAL_USE_VCLPLUGIN in .bashrc. Now LO comes up with qt6 when started from the command line. But when started from the application menu, or from firefox/thunderbird, or from the file manager, of course I still get the X11 version, not the qt6 version.
Did some more testing, found some more crashes (in addition to "export PDF") which are specific to gtk4 and do not happen with the qt6 backend: * Whenever calling "Help" (either using the help menu or the help button in a dialog), LO crashes, either immediately or after closing the dialog that tells me that help for the required language is not installed. * Menu "Insert", item "Envelope": Immediate crash * Menu "Tools", item "Footnote/Endnote settings": Immediate crash So please bring gtk3 back until gtk4 at least does not crash...
Had some discussions about gtk3/gtk4 and specifically the gtk4 LO backend with my students (computer science or business computing science, many of them coming from the government's IT department or public organizations). They don't care at all if it is gtk3 or gtk4. But they consider any user interface inconsistency or any violation of the user interface guidelines of the chosen desktop platform a very serious problem. Hence, client side decoration titlebars and even worse moving all important dialog buttons from the dialog bottom to the title bar (and some from the right to the left corner) is an absolute no-go, this is confusing and distracing for users which are not used to Gnome (and there are exactly zero students with a Gnome background and exactly zero users with a Gnome background in their organizations). This is even more the case because they have 95 % Microsoft Windows background and their linux background (if any) is with linux installations which try hard to look and feel as familiar as possible for Windows users (this is also true for the Gentoo server I run at the university for my students). Moreover, they explained to me that those buttons are against all ergonomic design guidelines: Dialogs are read and filled from top to bottom (and from left to right), at least in western civilizations, so the buttons which end a dialog must be at the bottom right corner of the dialog, because that's the position people naturally look at after working through the dialog, and that's the position where the input focus is expected after tabbing through all of the dialog, and that's the position where the mouse is usually close to after filling the dialog. They would happily accept a gtk4 UI if it conforms to the traditional user expectations and the interface guidelines of the desktop environment, and if it is consistent with all the other applications in that environment. But any Gnome-like design or behaviour differing from traditional environments is unacceptable in those environments. So if they used Gentoo in production (which they do not, at least not for installations where LO is relevant) they would require for UI consistency reasons: - either a traditional gtk3 LO backend, - or a gtk4 LO backend which automatically switches to traditional dialog layout and no client side decorations when used in any non-Gnome environment, - or two gtk4 LO backends, one for Gnome and one for all non-Gnome environments. And exactly the same is true for the Gentoo server I run for my students (running a relatively conservative Xfce): To convince my students that Linux is user friendly, students which have only used Windows up to now must feel at home immediately.
I confirm ugly interface. I try this under VM & xfce.
(In reply to Klaus Kusche from comment #3) > First of all, as I wrote above, the gtk4 backend reproducibly crashed LO > for me when opening the "export PDF" dialog. > Please file another bug for the crashing, ideally with a backtrace. Will need to also be filed upstream. > Secondly, there is some strange technical problem with the gtk4 backend > (or in fact with any backend except default X11): > I need to set SAL_USE_VCLPLUGIN explicitly. > This was *not* necessary with LO 24 and gtk3. > > I had LO compiled with gtk4, and I had installed gtk4 for it, > but without SAL_USE_VCLPLUGIN, LO still came up with the X11 backend. > yes, let's use this bug for that.
(In reply to Yuriy Dmitriev from comment #6) > I confirm ugly interface. I try this under VM & xfce. Wait, which is it? Stopped working (bug 950477) or something else?
In the meantime, this bug covers 4 topics: * The crashes. * The need for the environment variable and the fact that you get the X11 native interface (very ugly, way to small fonts, ...) even if you have gtk4 or qt installed and selected in the ebuild. * The fact that independent of styles and themes, all LO gtk4 dialogs have a CSD titlebar with all buttons moved from the lower right corner of the dialog to the left and right corner of the titlebar. A very disrupting and strange change in style and usability for any non-Gnome users! * The fact that I have only a (highly customized) gtk3 theme. It worked perfectly fine for the LO gtk3 backend. But LO's gtk4 backend can't read my gtk3 theme and uses gtk4's default theme, which is visually radically different from my gtk3 them: Completely different colors, different gui element style, different icons, too thin scrollbars for my high-res screen, ...
(In reply to Klaus Kusche from comment #9) > > * The need for the environment variable and the fact that you get the X11 > native interface (very ugly, way to small fonts, ...) even if you have gtk4 > or qt installed and selected in the ebuild. The bug is about this. We need another bug for the crashes. The other stuff is a bigger topic and not really something we can do anything about in Gentoo.
(In reply to Klaus Kusche from comment #9) > In the meantime, this bug covers 4 topics: No bug covers 4 topics. (In reply to Klaus Kusche from comment #9) > * The fact that independent of styles and themes, all LO gtk4 dialogs have a > CSD titlebar with all buttons moved from the lower right corner of the > dialog to the left and right corner of the titlebar. A very disrupting and > strange change in style and usability for any non-Gnome users! That is irrelevant for downstream packaging considerations. (In reply to Klaus Kusche from comment #9) > * The fact that I have only a (highly customized) gtk3 theme. > It worked perfectly fine for the LO gtk3 backend. > But LO's gtk4 backend can't read my gtk3 theme and uses gtk4's default > theme, which is visually radically different from my gtk3 them: Completely > different colors, different gui element style, different icons, too thin > scrollbars for my high-res screen, ... That is irrelevant for downstream packaging considerations.
(In reply to Andreas Sturmlechner from comment #11) > (In reply to Klaus Kusche from comment #9) > > * The fact that independent of styles and themes, all LO gtk4 dialogs have a > > CSD titlebar with all buttons moved from the lower right corner of the > > dialog to the left and right corner of the titlebar. A very disrupting and > > strange change in style and usability for any non-Gnome users! > That is irrelevant for downstream packaging considerations. Correct. I opened that one upstream today. https://bugs.documentfoundation.org/show_bug.cgi?id=165534 > (In reply to Klaus Kusche from comment #9) > > * The fact that I have only a (highly customized) gtk3 theme. > > It worked perfectly fine for the LO gtk3 backend. > > But LO's gtk4 backend can't read my gtk3 theme and uses gtk4's default > > theme, which is visually radically different from my gtk3 them: Completely > > different colors, different gui element style, different icons, too thin > > scrollbars for my high-res screen, ... > That is irrelevant for downstream packaging considerations. Of course you can't fix that in the gtk4 backend within Gentoo, and it also makes no sense to fix that upsteam, at least not in LO. Interestingly, qt6 automatically translated my gtk3 theme into a qt6 theme quite well, so perhaps gtk4 should do the same? Both topics are intended as a strong indication to bring the gtk3 LO backend back, because I expect the upstream CSD fix to take quite some time. LO worked perfectly fine for me and was broken in Gentoo by forcing the switch to gtk4.
(In reply to Andreas Sturmlechner from comment #11) > That is irrelevant for downstream packaging considerations. Would that the pseudonymous "downstream" deigned to package such prominent software to a standard befitting of a Linux distribution of Gentoo's stature instead of merely gatekeeping with snide clapbacks all day long and doing the bare minimum to silence QA checks (if that), after ignoring upstream's instructions to build with gtk3[1], and their warning that gtk4 is "under heavy development"[2] and consciously choosing to rice an office suite anyway. Maybe we as users need to ask LibreOffice whether it would consider communicating with the Gentoo Foundation in a manner similar to what OBS did with Fedora a week ago. Or you could just take the L. [1]: https://wiki.documentfoundation.org/Special:MyLanguage/Development/BuildingOnLinux [2]: https://wiki.documentfoundation.org/Special:MyLanguage/Development/GTK4
(In reply to Enne Eziarc from comment #13) > (In reply to Andreas Sturmlechner from comment #11) > > That is irrelevant for downstream packaging considerations. > Would that the pseudonymous "downstream" deigned to package such prominent > software to a standard befitting of a Linux distribution of Gentoo's stature > instead of merely gatekeeping with snide clapbacks all day long and doing > the bare minimum to silence QA checks (if that), after ignoring upstream's > instructions to build with gtk3[1], and their warning that gtk4 is "under > heavy development"[2] and consciously choosing to rice an office suite > anyway. It's not "ignoring" if one wasn't aware of it. My impression was, based on bug 902031, that the support had been around for some time and was mature enough. I'm sorry for the error. But it wasn't malice, it's the first I've been made aware of it, and there's no need for snark.
(In reply to Enne Eziarc from comment #13) > [1]: > https://wiki.documentfoundation.org/Special:MyLanguage/Development/ > BuildingOnLinux > [2]: https://wiki.documentfoundation.org/Special:MyLanguage/Development/GTK4 (I think [2] is pretty clear that we need to avoid gtk4, but I think calling [1] evidence of a recommendation is a bit lightweight.)
(In reply to Klaus Kusche from comment #12) > (In reply to Andreas Sturmlechner from comment #11) > > That is irrelevant for downstream packaging considerations. > > Correct. I opened that one upstream today. > https://bugs.documentfoundation.org/show_bug.cgi?id=165534 Thanks. > > (In reply to Klaus Kusche from comment #9) > > > * The fact that I have only a (highly customized) gtk3 theme. > > That is irrelevant for downstream packaging considerations. > > Of course you can't fix that in the gtk4 backend within Gentoo, > and it also makes no sense to fix that upsteam, at least not in LO. CSD is not a new topic at all, it's a thing since GTK3, even if not used by LO in that backend. Firefox e.g. has it too, but provides an option to disable it. It is unclear to me how GTK4 is any different in that regard as I am not involved in that toolkit's ecosystem. But it is not a topic for this bug. GTK4 support in our downstream LO packaging has been requested almost 2 years ago so I am a bit surprised it still has beta quality bugs. That, and my question in #comment 1 is the basis for our decision-making. Thanks to all those of our ~arch testers giving calm and constructive feedback.
(In reply to Klaus Kusche from comment #9) > In the meantime, this bug covers 4 topics: > > * The crashes. Confirm crash. File-->Export PDF. > > * The need for the environment variable and the fact that you get the X11 > native interface (very ugly, way to small fonts, ...) even if you have gtk4 > or qt installed and selected in the ebuild. > > * The fact that independent of styles and themes, all LO gtk4 dialogs have a > CSD titlebar with all buttons moved from the lower right corner of the > dialog to the left and right corner of the titlebar. A very disrupting and > strange change in style and usability for any non-Gnome users! > > * The fact that I have only a (highly customized) gtk3 theme. > It worked perfectly fine for the LO gtk3 backend. > But LO's gtk4 backend can't read my gtk3 theme and uses gtk4's default > theme, which is visually radically different from my gtk3 them: Completely > different colors, different gui element style, different icons, too thin > scrollbars for my high-res screen, ...
Please avoid excessive quoting. This bug comes with enough word padding already.
For themes: you may rename and check 25.2.1.1 -> 25.2.1.2. For me it looks much better, but still crashes.
(In reply to Andreas Sturmlechner from comment #16) > CSD is not a new topic at all, it's a thing since GTK3, even if not used by > LO in that backend. Firefox e.g. has it too, but provides an option to > disable it. It is unclear to me how GTK4 is any different in that regard as > I am not involved in that toolkit's ecosystem. But it is not a topic for > this bug. You are correct, the discussion is not new at all. And in theory, gtk3 is not significantly different from gtk4 wrt CSD: Both can do CSD and non-CSD. But in practice, the difference between gtk3 and gtk4 is huge: * Most non-Gnome gtk3 apps decided to stay with non-CSD, almost all gtk4 apps (which are mainly Gnome apps) are CSD. * Several gtk3 apps support both, mostly depending on the environment variable GTK_CSD (I think e.g. the Xfce code switches behaviour depending on GTK_CSD ?). But afaik, all gtk4 apps ignore GTK_CSD and can't be configured with CSD off. * Initially, the Gnome gtk3 users wanted CSD, so we had both opinions for gtk3. But now as Gnome and its apps have all moved from gtk3 to gtk4, the vast majority of remaining gtk3 users and desktops vote against CSD (and almost all gtk4 users vote for CSD).
(In reply to Yuriy Dmitriev from comment #17) > (In reply to Klaus Kusche from comment #9) > > In the meantime, this bug covers 4 topics: > > > > * The crashes. > > Confirm crash. File-->Export PDF. Have you checked my other crashes, too? * Menu "Insert", item "Envelope": Immediate crash * Menu "Tools", item "Footnote/Endnote settings": Immediate crash * Not having help installed for the language currently set, calling help in the menu or in any dialog
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(-)
Please have the discussion of crashes in another bug.
As requested: I've opened a new bug for the crashing gtk4 dialogs: Bug 950657
