E-Mail von Tobias Leupold vom Montag, 24. März 2025, 12:35: > E-Mail von David Redondo vom Montag, 24. März 2025, 09:22: > > This matches my investigation previously. Not sure why the Qt person was so > > dismissive that it was a Breeze bug from my limited knowledge Breeze looks > > to be doing correct things. Maybe I didnt word it clear enough? > > Just today, I commented again on https://bugreports.qt.io/browse/ QTBUG-133845 > > I don't get either why the Qt side states this was a Breeze bug. I mean, the > first commit fixing some Windows issue wouldn't trigger the problem yet > (because it asks the base style for the size and returns it). But the second > one leads to the desired final size being modified later on, causing this. > > Question is more: Why does this not happen using Fusion? > > And: Is Breeze even able to work around this? I mean, if a style sheet is set > on the QSpinBox in question, and thus, qstylesheetstyle comes into play, > Breeze would have to subtract the pixels the style adds later on before > returning it, so that we get the height we actually want to have ... > > Maybe one should have a look into Fusion to figure out what's going on in > there. At the latest when we show them that Fusion does fishy stuff on > QSpinBoxes, they can no longer claim this was a Breeze bug. > > Maybe some Breeze dev could step in to clarify this?!
Looking at Fusion, it does call QCommonStyle::sizeFromContents() in sizeFromContents() to intialize a QSpinBox's size before procesing it later on. Breeze does not do this, cf. https://invent.kde.org/qt/qt/qtbase/-/blob/6.8.2/src/widgets/styles/ qfusionstyle.cpp?ref_type=heads#L3018 Until the two commits mentioned, qstylesheetstyle did not query Breeze for the QSpinBox size at all, but got the size from somewhere else -- and it (maybe coincidentally?!) matched the desired size. Maybe, Breeze actually should also query QCommonStyle and adjust the size when painting or such? Just a random shot though ...
