Created attachment 119874 [details] Mixed screenshot of two hovered buttons with different heights SUMMARY Height of the button with a small icon and no text is less, than the one's with text. STEPS TO REPRODUCE 1. Open any KDE application with a toolbar (e.g. Gwenview) 2. Set the icon size in the toolbar to "Small (16x16)" and the text position to "Text alongside icons". 3. Make one button have a text (e.g. "previous" button on a screenshot) 4. Make another button have no text. 5. Now hover to each of them to see border boxes with different height sizes with the difference approximately equal to 1 or 2 px. OBSERVED RESULT Blue border boxes of buttons have different height. EXPECTED RESULT Blue border boxes should have the same height, because icon size is the same too. SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.15.80 KDE Frameworks Version: 5.58.0 Qt Version: 5.12.0 Kernel Version: 4.18.0-18-generic OS Type: 64-bit Processors: 4 × Intel® Core™ i7-8550U CPU @ 1.80GHz Memory: 3,9 GiB of RAM ADDITIONAL INFORMATION Font is the default one - Noto Sans 10pt If icon size is larger than small (16x16) (e.g. medium, large), button heights are the same, which is works as intended/.
I don't think this should be changed in Breeze. If you have large font size (say 40 pixels height), but only want a button with an icon, which is only 16 pixel height, then the button shouldn't allocate the 40 pixels for the text. I am reassigning to Gwenview, because it could set a minimum size for the buttons to accomodate both the font size as well as the icon size.
It's worth mentioning that with the default toolbar icon size settings (22px icons), the heights do match up. Not sure this makes sense to change in only Gwenview. If there's anywhere it does make sense to change, it would be in Breeze. If a user does something crazy like set 40pt font, nothing else is going to work right, so I'm not sure it makes sense to optimize around that.
Created attachment 120233 [details] Dropdown button height mismatch in Gwenview Well 40px font is a bit extreme, but if I understand correctly, button heights mismatch because font height is greater, than the icon's one, and buttons define their heights according to content. So, I think it's a more fundamental problem, than fonts and icons - take a look at "Open With" dropdown button in Gwenview, it's height is way smaller, than rest of items on left. It also applies to other widgets, for example, page size combobox in Okular. The heights of toolbar items should be equal to toolbar height, I think. In case of extreme scenarios (like on dropdown menu button on a screenshot) it won't only look nice - this will increase click area too. However, in case of comboboxes (like in Okular) I'm not sure about the look, the combo looks strange in my opinion.
Created attachment 120234 [details] Okular short in height combox
Created attachment 120235 [details] Okular possible tall combobox
Agreed.
I don't agree, the tall comboboxes really look out-of-place. In Skulpture I forced SmallIcons size to the same size as the font size, so that buttons with icons and text get the same height. They got blurry, though, but that shouldn't be an issue now that we have scalable icons, so we could revisit that idea. But this won't work for the toolbar case, because toolbar icons can have any size. What you show here is "text is smaller than icon+text", which is of course always the case.
If there's way to make the heights identical only when they would otherwise be off by a pixel or two, that would probably be ideal.
Created attachment 120890 [details] Okular combobox with caption Agreed, the tall combobox is odd. Instead we could just use a caption "Scale" in "Text under icons" mode.
*** Bug 411811 has been marked as a duplicate of this bug. ***