Description: escription: I just got a laptop with a 4K screen and am using 250% scale factor, for an effective DPI of 240 (However the bug I am about to describe also happens with 200% scale/192 DPI). I am using the 7.0 daily AppImage which includes better HiDPI support for the KDE5 VCL. Here are the remaining issues: - Toolbar and menu item icons are pixellated, not sharp. - The Hamburger menu in the ribbon is too small Steps to Reproduce: 1. Have a 4K screen 2. Set a scale factor of 200% or greater in KDE System Settings 3. Open a LibreOffice app 4. Use the Ribbon UI Actual Results: Various UI elements are scaled incorrectly (See above). Expected Results: All UI elements are scaled perfectly. Reproducible: Always User Profile Reset: Yes Steps to Reproduce: 1. Have a 4K screen 2. Set a scale factor of 200% or greater in KDE System Settings 3. Open a LibreOffice app 4. Use the Ribbon UI Actual Results: All toolbuttons on the ribbon that consist of an icon with text underneath it and a downward-pointing arrow to the right have the arrow sized to be too large. Expected Results: The arrows are the right size Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.0.0.0.alpha1+ Build ID: 6ba74150866d71469827de9f4f19268dfa7db137 CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5; Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-05-07_15:09:13 Calc: threaded
Created attachment 162084 [details] Arrow too large, 1
Created attachment 162085 [details] Arrow too large, 2
Created attachment 162086 [details] Arrow too large, 3
This is a dupe/continuation of work on 122118 Was Hieko's patch only effective on Toolbar and not NB? @Jan-Marek, would similar approach to the Hamburger help tame the odd scaling of the reveal triangles on Toolbar/Notebook Bar at higher scale factors?
Toolbox and NB are the same code. This currently looks like a generic VCL bug in the toolbox code, but I'm not sure. That code needs some larger inspection and probably a bit of refactoring. It also has some buggy code in the KF5 VCL for the scaled button size calculation, introduced by the HiDPI patch, which I missed when reviewing it. And I currently don't understand it, neither by looking at the controls VCL code, especially Heikos change and comment, nor the gtk3 implementation.
(In reply to Jan-Marek Glogowski from comment #5) > Toolbox and NB are the same code. This currently looks like a generic VCL > bug in the toolbox code, but I'm not sure. That code needs some larger > inspection and probably a bit of refactoring. > > It also has some buggy code in the KF5 VCL for the scaled button size > calculation, introduced by the HiDPI patch, which I missed when reviewing it. > > And I currently don't understand it, neither by looking at the controls VCL > code, especially Heikos change and comment, nor the gtk3 implementation. Could not reproduce on Windows 10 / Debian Gnome with 7.0 beta. For the images I gess the user is using KDE plasma desktop environment. If I'm not wrong it uses Qt instead of GTK or Skia could it be issue with Qt or the icon theme? If this is duplicate of bug 122118 should be closed since it is closed.
Created attachment 162088 [details] Win10 with recent 7.1.0alpha0+ build at 250% UI scaling, Tabbed NB UI 'Layout' tab (In reply to dante19031999 from comment #6) > > If this is duplicate of bug 122118 should be closed since it is closed. No it is not a duplicate, Heiko wanted the other closed. But at higher os/DE UI scaling the VCL drawn reveal triangles are out of scale/positioning. A bit more reasonable with Standard UI and on some of the other NB panels--but clearly an issue with the control. Screen clip from Windows 10 (1909) at 250% custom scale factor, with recent TB77 build: Version: 7.1.0.0.alpha0+ (x64) Build ID: a201ab6f47c2d5a7ba4c5f998b0aa231cae82010 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Created attachment 162486 [details] Wrongly positioned icon and text visible on mouse-over. Just in case you didn't notice, the Windows and KF5 problems are different. On Windows the arrows are not only too big, but these don't fit into the button drawing area at all. This is very likely a problem in the Windows native styling code. For KF5 (or generally) "just" the positioning of the text and icon is "wrong". You can see this, if you highlight the button with mouse over (see the image). And if you open the drop-down, the button is also wrongly highlighted, overwriting the icon and text. That is a general problem of the VCL widget and is fixed by https://gerrit.libreoffice.org/c/core/+/97358 This horizontally centers icon and text in the area left of the drop-down button, so they won't overlap. There is still the scaling / size issue. It looks like the triangle size is related to the button size, so bigger buttons get bigger triangles. Honestly I have no idea, what size is "correct". I guess bug 122118 didn't investigate the size in any HiDPI mode, so the scaling is now off. Maybe the size should not depend on the button size, but on the font size? In this case all the triangles in the toolbox would become the same (size).
Should be an easy hack, see comments on the duplicate. *** This bug has been marked as a duplicate of bug 130991 ***
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8565546ce6a04f6f243f4f60d2693b148dca5a77 tdf#134054 toolbox: respect drop-down arrow rect It will be available in 7.1.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.
Jmux, what about the duplicate bug 130991? Shall we also resolve it as fixed?
(In reply to Heiko Tietze from comment #11) > Jmux, what about the duplicate bug 130991? Shall we also resolve it as fixed? No. This patch is not a fix for the size problem, just for the overlapping drawing in the VCL widget. You can see this bug in my attached image. Maybe I should have created yet an other bug report, but I was too lazy. The original report is still valid and so is especially the last paragraph in my comment 8.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/62b4803b32963f9529e6380f14a5b7d4edb8c4ff tdf#134054 toolbox: respect drop-down arrow rect It will be available in 7.0.0.1. 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.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4bb8bb043f61befd755e090bf966efd24a83c345 tdf#134054 Qt5 really scale the toolbox button It will be available in 7.1.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.
This additional patch just fixes the Qt5 side, but it depends on the fixes for bug 130991. In hindsight I should have moved the first patch to this other bug too, but digging into both bugs unveiled multiple implementation problems; all the separation is now a bit mood, but should be fixed when I have merged the last patch still waiting for Jenkins.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/499ea815432eee3d0555aae96927c2568dbaf5d5 tdf#134054 Qt5 really scale the toolbox button It will be available in 7.0.0.1. 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.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/eee6441bc9eea847ba4b338baf99ab47913fcd61 tdf#134054 toolbox: respect drop-down arrow rect It will be available in 6.4.6. 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 can confirm the fix in the latest daily builds. Thanks!