Created attachment 147567 [details] Screenshot (Windows) The little triangles next to dropdown toolbar buttons are too large. See comparison screenshot. Observed using LO 6.3.0.0.alpha0+ (68aef0a3df1dd4c83dc3c26e4d3280649f4d3265) / Windows 7. Looks fine in 6.2 beta1. => regression Bibisected to the following commit using repo bibisect-win32-6.3. Adding Cc: to Michael Meeks, please take a look. https://cgit.freedesktop.org/libreoffice/core/commit/?id=b62c43d1200e524369d9c7c2bd1dad3044efd672 author Michael Meeks <michael.meeks@collabora.com> 2018-11-23 02:14:00 +0000 committer Michael Meeks <michael.meeks@collabora.com> 2018-11-26 18:54:08 +0100 Anti-alias toolbar button drop-downs.
confirm for Version: 6.3.0.0.alpha0+ Build ID: 3c964980da07892a02d5ac721d80558c459532d0 CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2018-12-12_02:07:45 Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded
I wouldn't agree this is a bug. Triangles are larger but not too large for me.
Besides Timur's comment, I doubt it is a Colibre icon. Rather the system theme has changed.
Created attachment 147735 [details] Screenshot (Linux) (In reply to Heiko Tietze from comment #3) > Besides Timur's comment, I doubt it is a Colibre icon. Rather the system > theme has changed. The triangles are drawn programmatically. I'd say the change looks fine on Linux, but they are too large on Windows.
Okay, let's make it a pixel smaller, ideally depending on the toolbar size (gtk3 dropdowns are quite large while qt is smaller too). Could be an easyhack with code pointers.
(In reply to Heiko Tietze from comment #5) > Okay, let's make it a pixel smaller, ideally depending on the toolbar size > (gtk3 dropdowns are quite large while qt is smaller too). Could be an > easyhack with code pointers. +1
Created attachment 148236 [details] Screenshot with the patch Triangle size depend now on the height of the toolbar. Patch is here https://gerrit.libreoffice.org/#/c/66166/, comments are welcome.
can I have a screenshot of the tabbed notebookbar cause there are some commands with size small and others with labels on bottom so the toolbar height will be two rows.
Created attachment 148237 [details] gen and gtk3/Breeze Not sure that NB uses the same routines.
(In reply to Heiko Tietze from comment #9) > Created attachment 148237 [details] > gen and gtk3/Breeze > > Not sure that NB uses the same routines. see first icon which is two rows high, has larger arrow. don't know if you like it.
(In reply to andreas_k from comment #10) > ... don't know if you like it. Worse that some buttons are so small that the triangle is just a few pixels big. The question is rather how we deal with that per a) having a minimum/maximum size, b) require NB controls to have a minimum size, c) change the algorithm to be more conservative, d) refuse the change and accept bigger triangles in standard etc. Would also be very interesting how all this works on hires screens.
FYI; I would suggest just reverting my patch if we think it makes things better and getting that into 6.2. The change is mostly helpful for HiDPI in Online anyway - which we don't use for PC / HiDPI yet (sadly).
Nb follow icon settings default is sc_ so 16px but 24 pix is also possible via settings.
(In reply to Heiko Tietze from comment #7) > Patch is here https://gerrit.libreoffice.org/#/c/66166/, comments are > welcome. Sadly in Windows this patch makes no difference, perhaps that needs different constants in the formula. (In reply to Michael Meeks from comment #12) > FYI; I would suggest just reverting my patch if we think it makes things > better and getting that into 6.2. The change is mostly helpful for HiDPI in > Online anyway - which we don't use for PC / HiDPI yet (sadly). The original commit was only pushed in master, after branch-off, so 6.2 isn't affected.
Would keep Michaels patch and this too as it also solves the problem with too small triangles at extra large icons. Added now a minimum value. Don't see why Windows need different constants, maybe you run a hires display, which should be covered by the other factor.
(In reply to Heiko Tietze from comment #15) > Don't see why Windows need different constants, maybe you run a hires > display, which should be covered by the other factor. 1920x1200, not particularly high resolution.
Pushed it to master. QA, please test this carefully.
heiko tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/b56ad2a1292b01647c4ee1f4364f7c4aa20fc449%5E%21 Resolves tdf#122118 - Toolbar dropdown button triangles are too large It will be available in 6.3.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 #18) > heiko tietze committed a patch related to this issue. >... Which is being reverted because of bug 122761, I will look into it.
Xisco Faulí committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/59647fa4d190622cc6aae873de06a4dfe973bd54%5E%21 tdf#122761: Revert "Resolves tdf#122118 - Toolbar dropdown button triangles are too large" It will be available in 6.3.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.
https://gerrit.libreoffice.org/#/c/66565/3 Second try, please test.
heiko tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/e3cc5506d695b602fbd3c6ee816e36e6a76d9d96%5E%21 Resolves tdf#122118 - Toolbar dropdown button triangles are too large It will be available in 6.3.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.
Created attachment 148741 [details] Windows GL vs no GL Interestingly with OpenGL disabled it looks good now, but with OpenGL enabled, not so much.
(In reply to Aron Budea from comment #23) > Interestingly with OpenGL disabled it looks good now, but with OpenGL > enabled, not so much. Could that be related to bug 122457? Anyway, I'm more interested if the size works on hires screens; the patch doesn't touch the DrawPolygon() function.
A polite ping, still working on this bug?
Dear Heiko Tietze, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.
Questionable patch, see c23, c24. But better we close this ticket and start new.