Created attachment 178072 [details] LO as it looks scaled in Wayland - Neon user edition
Created attachment 178073 [details] LO started up in an unofficial way
When I use Writer in the official way and scale it in Wayland it does scale but it looks far from perfect. Imho the styles-box is too small, font in the tabs is too big, there is not enough space between the items in the "ribbon" bar. When I startup Writer using Exec= QT_QPA_PLATFORM=xcb QT_SCALE_FACTOR=1 lowriter it will look as in the second attachment. Imho this is perfect. But it needs this workaround. Just to give you some feedback on your great work. My system: Operating System: Kubuntu 21.10 KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.13.0-28-generic (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i5-4300U CPU @ 1.90GHz Memory: 3.7 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4400
Thanks for your feedback. Some questions to better understand this: (In reply to pieter kristensen from comment #2) > When I startup Writer using Exec= QT_QPA_PLATFORM=xcb QT_SCALE_FACTOR=1 > lowriter > it will look as in the second attachment. Imho this is perfect. But it needs > this workaround. As far as I understand, QT_SCALE_FACTOR=1 effectively disables scaling. What does it look like if you just do QT_SCALE_FACTOR=1 lowriter i.e. the same without switching to the xcb/X11 platform integration in addition. Does it look different from the result of the command you mentioned? (i.e. is Wayland relevant here or not) What scaling options do you have applied to your screen(s) otherwise? How many screens do you have and what resolution? What variant of the tabbed interface did you set in "View" -> "User Interface" (or wherever that option is in the tabbed interface)?
Created attachment 179395 [details] LO looking bad 125% scaled
Created attachment 179396 [details] way I scaled
- What does it look like if you just do QT_SCALE_FACTOR=1 lowriter? When I scale to 100% or less it looks perfect, when I scale to bigger it is a mess. (attachement) - What scaling options do you have applied to your screen(s) otherwise? How many screens do you have and what resolution? Again I attach an image. I think the only thing I do is "fractional scaling". - What variant of the tabbed interface did you set in "View" -> "User Interface" (or wherever that option is in the tabbed interface)? I use the plain tabbed version. Not compact or grouped or so.
Btw, when I paste QT_SCALE_FACTOR=1 in the konsole and press Enter to start LO-Writer, the console gives this output to me qt.qpa.wayland: Wayland does not support QWindow::requestActivate() (four times in a row) but after that LO starts.
This is far beyond me but I read a guy on the internet who said that he "compiled LO with a higher QT version" (again, I don't understand anything of this) and the scaling problems in Wayland were magically gone.
Thanks for the quick reply, which helps a lot. > - What scaling options do you have applied to your screen(s) otherwise? How > many screens do you have and what resolution? > Again I attach an image. I think the only thing I do is "fractional scaling". That shows its a single screen with resolution 1920x1080, i.e. this is not about the issue described in tdf#141578. The screenshot shows 100% scaling, but from your text and the description of attachment 179395 [details], 100% should be fine and it's problematic e.g. with 125% instead, correct? > - What variant of the tabbed interface did you set in "View" -> "User > Interface" (or wherever that option is in the tabbed interface)? > I use the plain tabbed version. Not compact or grouped or so. Does it look as expected when you try "Standard Toolbar" instead, or does it still look broken? (In reply to pieter kristensen from comment #8) > This is far beyond me but I read a guy on the internet who said that he > "compiled LO with a higher QT version" (again, I don't understand anything > of this) and the scaling problems in Wayland were magically gone. tdf#137924 has more details, in particular tdf#137924 comment 13. In short, if you use 7.3.0 (the version given in the "Version" field) or newer from your distro (KDE Neon, having 5.15.2 according to comment 2), that's fine. If you're using the TDF-provided packages, you'll still run into the problems described in tdf#137924 because those are compiled with an older Qt version. How did you install the LO you were using when you ran into the issues described here? (In reply to pieter kristensen from comment #7) > Btw, when I paste QT_SCALE_FACTOR=1 in the konsole and press Enter to start > LO-Writer, the console gives this output to me > qt.qpa.wayland: Wayland does not support QWindow::requestActivate() > (four times in a row) but after that LO starts. That's unrelated. When I just run Writer with the tabbed interface and 125% scaling on a 1920x1080 screen, that looks quite sane in my Plasma Wayland session on Debian Wayland, s. attachment, not like your attachment 179395 [details]. However, then again, your attachment 178072 [details] looks similar and the initial description in comment 3 was about smaller issues than the brokenness in attachment 179395 [details], IIUC. So I'm wondering whether you're using different LO builds (e.g. one from your distro, one from TDF) and we're mixing different things here. Let's try to identify the single aspects and what's still relevant in the current development version with a new enough Qt, because that would be what still needs work from a development side. Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 365bd679904ec5f67d1061511d7faf73f9f8aa62 CPU threads: 4; OS: Linux 5.16; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Created attachment 179400 [details] The screenshot mentioned in comment 9
Another note: Can you please double-check whether things change if you log out, then in again after changing your display settings/scaling? (At least for me, things sometimes looked much better after that, not only for LibreOffice.)
I hope I understood you well. So I took the version Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 55b20c8781d7718fa992769df90282563694f7fe CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+wayland) Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded this time. I scaled to 125% then rebooted and the result looks exactly just as ugly as when I am using my distro's version (neon user). attached
Created attachment 179403 [details] LO 7.4 alpha scaled to 125%
(In reply to Michael Weghorn from comment #9) > Let's try to identify the single aspects and what's still relevant in the > current development version with a new enough Qt, because that would be what > still needs work from a development side. Sorry, that comment seems to have been rather misleading. > I hope I understood you well. So I took the version Version: > > 7.4.0.0.alpha0+ / > LibreOffice Community > Build ID: 55b20c8781d7718fa992769df90282563694f7fe > CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+wayland) > Locale: nl-NL (nl_NL.UTF-8); UI: en-US > Calc: threaded > > this time. > I scaled to 125% then rebooted and the result looks exactly just as ugly as > when I am using my distro's version (neon user). attached Given that TDF-provided packages are built against an older version of Qt, using scaling on Wayland is expected to result in bad results because the fix for tdf#137924 does not apply there. Therefore, unless you want to build LO from source yourself, the packages provided by KDE Neon should currently give better results than the one from the LibreOffice website. My suggestion would therefore be to focus on those, and I can retest here whether the same issues are still present in the current development version of LibreOffice (I'm building LO from source, so have a new enough Qt version.) Was attachment 179395 [details] made with the KDE Neon packages for LibreOffice? If so, what version did you use for attachment 178072 [details], which looks much better? There's also tdf#146297, which sounds like it might cover the issues mentioned in comment 2.
what version did you use for attachment 178072 [details], which looks much better? I had to look... But the stock LO version of Ubuntu Focal Fossa (april 2020) is 6.4.7.2 Build ID: 1:6.4.7-0ubuntu0.20.04.4 CPU-threads: 4; Besturingssysteem: Linux 5.13; UI-render: standaard; VCL: kf5; This must be the release of attachment 178072 [details] that looks better (and in fact looks a lot like your Debian screenshot)
(In reply to Michael Weghorn from comment #14) > Was attachment 179395 [details] made with the KDE Neon packages for > LibreOffice? Can you please copy the information from "Help" -> "About LibreOffice" here for the version that you were using for that screenshot? If it's the version from Ubuntu 21.10, then https://packages.ubuntu.com/search?keywords=libreoffice&searchon=names&suite=impish§ion=all suggests that that would be 7.2.x, in which case the fix for tdf#137924 would not be included. (So far I was assuming it would be 7.3, which the "Version" field is set to.) If it's actually 7.2, the brokenness is basically expected. Using the Ubuntu PPA to get a newer LibreOffice version might help in that case.
The screenshot you refer to, attachment 179395 [details], is the "still" version. According to the libreoffice-still ppa. It is the 7.2 version. Scaling is not an option with that version. If you need to change the size of LO 7.2, (because you have a 4k screen or so, it only can be done using the tweak: Exec= QT_QPA_PLATFORM=xcb QT_SCALE_FACTOR=1 lowriter The older version (stock Focal Fossa 6.x) does reasonably well. I installed the fresh-ppa and at the moment LO in that version won't run. So I can´t tell how it does with scaling...
Thanks for the clarification! (In reply to pieter kristensen from comment #17) > The screenshot you refer to, attachment 179395 [details], is the "still" > version. According to the libreoffice-still ppa. It is the 7.2 version. > Scaling is not an option with that version. If you need to change the size > of LO 7.2, (because you have a 4k screen or so, it only can be done using > the tweak: Exec= QT_QPA_PLATFORM=xcb QT_SCALE_FACTOR=1 lowriter That's tdf#137924 then, which is only fixed from 7.3 on (and with a new enough Qt version) when using the so-called kf5 VCL plugin", which is used by default on KDE Plasma. > The older version (stock Focal Fossa 6.x) does reasonably well. > I installed the fresh-ppa and at the moment LO in that version won't run. So > I can´t tell how it does with scaling... Oh... That sounds like something the PPA provider would have to look into... Given that, can we close this bug as a duplicate of tdf#137924, since the other aspects mentioned in comment 2 are tracked in tdf#146297?
What you can try with the still version is to set the SAL_FORCE_DPI environment variable, as described in this comment: https://bugs.documentfoundation.org/show_bug.cgi?id=137924#c14 With a scale factor of 125%, SAL_FORCE_DPI=120 may work.
Created attachment 180790 [details] "avatars" of recently used files are still not properly scaled (too small) I just tried LO 7.4 beta 1 and the "avatars" of the recently used files in the start-center are imho still not properly scaled in wayland. They are too small. I use plasma 5.25 and Neon user edition.
Created attachment 180791 [details] Styles box in LO Writer 7.4 beta 1 still not properly scaled in Wayland The styles box of LO Writer 7.4 beta 1 also still isn't properly scaled on my Neon user edition plasma 5.25 machine.
Thanks for retesting! (In reply to pieter kristensen from comment #20) > Created attachment 180790 [details] > "avatars" of recently used files are still not properly scaled (too small) > > I just tried LO 7.4 beta 1 and the "avatars" of the recently used files in > the start-center are imho still not properly scaled in wayland. > They are too small. > I use plasma 5.25 and Neon user edition. Can you please create a separate bug report for this? The behavior is the same when I start LO with the kf5 VCL plugin in a Plasma X11 session with env variable QT_SCALE_FACTOR=4 set, so that's not Wayland-specific. (In reply to pieter kristensen from comment #21) > Created attachment 180791 [details] > Styles box in LO Writer 7.4 beta 1 still not properly scaled in Wayland > > The styles box of LO Writer 7.4 beta 1 also still isn't properly scaled on > my Neon user edition plasma 5.25 machine. There is already a separate bug report for this: tdf#146297 Let's close this "more generic" bug report and handle the remaining issues in separate tickets. *** This bug has been marked as a duplicate of bug 137924 ***
insanetree committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0cf5141b2233611286a27930d8030c562eb0d84b tdf#147201 Use std::size() instead of SAL_N_ELEMENTS() macro It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #23) > insanetree committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 0cf5141b2233611286a27930d8030c562eb0d84b > > tdf#147201 Use std::size() instead of SAL_N_ELEMENTS() macro > > It will be available in 7.5.0. > > The patch should be included in the daily builds available at > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > https://wiki.documentfoundation.org/Testing_Daily_Builds > > Affected users are encouraged to test the fix and report feedback. I'm sorry to say that I tried the first alpha of 7.5 and the problem is still there. Nothing seems to have changed at all...
(In reply to pieter kristensen from comment #24) > I'm sorry to say that I tried the first alpha of 7.5 and the problem is > still there. Nothing seems to have changed at all... The commit from comment 23 looks completely unrelated to this, and probably just shows up here because of a typo in the bug number in the commit message. As mentioned in comment 22, the remaining issues are tracked in separate bug tickets.