Created attachment 158240 [details] 6.4.1.2 arrows to big Toolbar arrows too large on 200% scaling last version which is fine is 6.2.x See attachment for illustration.
200% sounds like much scaling. 8k display? ;-) Don't think we can do much, see bug 122118. The triangles are drawn as long width = round(rDropDownRect.getHeight()/5.5) * fScaleFactor; // scale triangle depending on theme/toolbar height with 7 for gtk, 5 for gen long height = round(rDropDownRect.getHeight()/9.5) * fScaleFactor; // 4 for gtk, 3 for gen if (width < 4) width = 4; if (height < 3) height = 3; https://opengrok.libreoffice.org/xref/core/vcl/source/window/toolbox.cxx?r=4a08d20e#2374 But I'd keep the ticket open to see if more complaints come in.
How are the triangles drawn in versions till 6.2.8.2? This version looks good to me, I am on 200 % scaling for 4 years and LibreOffice was always fine and nice to look at it, but the arrows seems to be to big. See also new camparison screenshot.
Created attachment 158758 [details] comparison of 6.2.8.2 and 6.4.1.2
Created attachment 158759 [details] comparison of 6.2.8.2 and 6.4.1.2
(In reply to Klaus1189 from comment #3) > Created attachment 158758 [details] > comparison of 6.2.8.2 and 6.4.1.2 bug 122118 refers to this patch https://cgit.freedesktop.org/libreoffice/core/commit/?id=b62c43d1200e524369d9c7c2bd1dad3044efd672 Reason was likely the introduction of antialiasing but the past drawing function was also not really convincing while( width >= 1) { rRenderContext.DrawRect( tools::Rectangle( x, y, x+width-1, y ) ); y++; x++; width -= 2; } If we go ahead, and I would do only if more complaints come in, we should reduce the effect of scaling like long width = round(rDropDownRect.getHeight()/5.5) * fScaleFactor * 0.9; I introduced the values of 5.5 and 7 for bug 122118 by trial and error as approximation to the normal expander triangle at 100%. Doing the same for higher scaling makes no sense without hires screen.
Thanks Heiko - of course, having a properly AA thing would be lovely; for the precision there, I guess we should have multiple sizes of pre-drawn bitmap (or something) =) Then again - much of the UX would be better as native, platform rendered & themed widgets I think - in the deep future.
I have same bug...
*** Bug 132178 has been marked as a duplicate of this bug. ***
I just downloaded 6.4.3 and the arrows still look way too big. Going back to 6.2.8 Have you developers plans to go back to 6.2.8 arrows which look perfect?
Please implement patches quickly, it would be a shame to stop using LibreOffice after many years. In the current form of the program it is practically impossible to use.
Hi all, this is an easy hack - anyone who feels passionately about this can build LibreOffice and tweak the code Heiko pointed at and that is linked in that patch to get something they like better, and then send their first patch. Thanks.
Hi, I downloaded 6.4.4 and the issue still persists. I beg to go back to 6.2.x look.
*** Bug 134054 has been marked as a duplicate of this bug. ***
So I had a look into this, and it's no easy hack. While the arrow now scales, the assigned drop-down-arrow rectangle doesn't. You can see this in the attached images, where the arrow is painted out-of-bounds and overlaps with other widgets. In fact the reported size to the native painting code is always 11px, the TB_DROPDOWNARROWWIDTH. If you highlight the button with the mouse, you'll see the too small dividing line between the button and the drop-down-arrow. This is also visible in my attached images of bug 134054, but that had in addition a broken implementation of the native button sizing code in the Qt5 VCL backend. Now interestingly there is some IOS code there, which probably needs some additional fixup now: - long nDropDownArrowWidth = TB_DROPDOWNARROWWIDTH; + long nDropDownArrowWidth = TB_DROPDOWNARROWWIDTH * fScaleFactor; #ifdef IOS nDropDownArrowWidth *= 3; #endif And I don't know if any platform code works around this problem in the VCL plugin. IMHO that IOS code should be removed too, but since I don't know anything about IOS, and interested party has to review the (multiple) patches.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1eba1c4597f8c2698aa91e2218d8452ad0fbc39c tdf#130991 Scale the drop-down arrow size-request 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.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/17b75eb1d7032f8ff85d9af1ec635fa1800cca1e tdf#130991 Fit the drop-down arrow into its 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.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/f0daeb39aa61cc3435630cf0b9727f6da818de1a tdf#130991 Scale the drop-down arrow size-request 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-7-0": https://git.libreoffice.org/core/commit/b0315eb69c62f2108983e6a4b2177cf28a2663bf tdf#130991 Fit the drop-down arrow into its 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 "libreoffice-6-4": https://git.libreoffice.org/core/commit/c0971961cf11097c787c67b5892d6209f89662e7 tdf#130991 Fit the drop-down arrow into its 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.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/9921be1f47943781c443927f7c7d94a460f2780b tdf#130991 Scale the drop-down arrow size-request 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 installed 7.0.0.1 and the issue is fixed. Thank you very much for this. I checked installer on 200% scaling ass well and it is fine as well. Nice ;) But I got two other cosmetics to be delt with, so official 7.x.x stable/final is looking good. I have still 3840x2160p display and windows is sclaed to 200%, then I encounter this in pre 7.0.0.1: - The filename is cut off when hoovering the mouse onto a recent document the user edited. -> "cut off 7.0.0.1.png - In german translation "Zuletzt verwendete Dateien" for recent files or similar on english version, the last "n" of "Dateien" is cut in half by the drop down arrow box -> "7.0.0.1" should I create new bugs for these, or is it enough here? Thank you guys :)
Created attachment 162876 [details] 7.0.0.1.png
Created attachment 162877 [details] cut off 7.0.0.1.png