Possibly caused by the menu-button integration. To reproduce: - compare toolbar size from one month ago to todays toolbar size. git master
Which toolbars where? What app(s)? What menu-button integration are you referring to, exactly?
Created attachment 153469 [details] Screenshot highlighting the margin change All toolbars in KDE/Qt application windows. Screenshot for kcharselect added. Regarding the menu button, this was just a blind guess. I'm totally out of loop concerning recent developments, but I read somewhere about a new toolbutton to integrate the menubar into the toolbar.
KCharSelect isn't one of the apps that has been ported to that yet (it's called KHamburgerMenu), so I don't think that's a factor. I can confirm what you're talking about, but I'm not aware of any recent changes to toolbar height, and the current state of git master feels nice to me, so I haven't noticed anything that seemed like an obvious regression. I went waaaay back and found that this was introduced with https://invent.kde.org/plasma/breeze/-/commit/509ff6bc48f4baef7e0965071f9ee5b5a1840474 in 2020. The extra spacing is intentional when using a color scheme with Header colors, to make room for the line below the toolbar that appears. But when using a non-Header-color-using color scheme, this is unnecessary and we should probably go back to the old spacing.
I update to master about once per month, and the margin wasn't there before yesterday's update.
I can't reproduce that by going back to older Breeze versions. If this issue isn't caused by a recent Breeze regression, then it would have to be in KXMLGui or Qt, I guess. Still, we did find an actual Breeze issue here. :)