By default, a focus frame should only be drawn for a selected list of
widgets. But if an application developer explicitly adds a QFocusFrame
for some other widget that Breeze doesn't handle by default, then the
frame should also be drawn.
The minimum required KF is 5.90, but the namespaced include of
TabletModeWatcher didn't exist until KF 5.91. Use the old non-namespaced
include, if the namespaced include doesn't exist.
We don't do any mirroring of the slider groove rects or tickmarks based on layout direction,
and this causes qqc2-desktop-style sliders to render in the wrong direction.
Swapping the leftRect and the rightRect when option->direction == Qt::RightToLeft
fixes this.
This wasn't broken with QWidgets because QSlider relies on (ab)using the upsideDown option
in order to achieve mirroring of the groove instead of option->direction, and consequently,
this change doesn't affect Qt widgets apps at all.
BUG: 430101
While Breeze draws no frames around toolbars, yet it had the style hint
for the frame width set to 6, while having the actual toolbar margin
set to 0.
The possible cause is that PM_ToolBarItemMargin was only introduced for
Qt4, so seemingly Qt3 times' workaround to set the margin via the frame
width instead of having more of the CSS box model now available missed
to be adapted to in the minds of the style developers.
Qt's own codee uses PM_ToolBarItemMargin & PM_ToolBarFrameWidth to
calculate the QToolbar layout's contentmargin, so switching the values
results in no actual change there.
The only other use is PM_ToolBarFrameWidth for initializing the
QStyleOptionToolBar::lineWidth, which though is unused by Oxygen drawing
code, so the change also has no effect.
But 3rd-party code querying the pixel metric for these two values after
this patch gets proper values and can properly align custom UI painting with the
styled toolbar.
Sometimes button labels in a ToolButton without icon and a ToolButton
with icon are not vertically aligned even if all buttons have the same
height. This is caused by double-to-int.
The original top padding `(contentsRect.height() - textSize.height()) / 2`
can be rounded down, and when the padding is rounded down, so
`contentsRect.height() - padding - textSize.height() ≠ padding`.
After this change, textRect is calculated based on the remaining space.
For example, `contentsRect.height() = 32`, and `textSize.height() = 15`,
so the padding is 8. Before this commit, the bottom padding will be
`32 - 8 - 15 = 9 ≠ 8`. After this change, the bottom padding is the
same as the top padding (8), so the visual glitch is fixed.
The cursor build scripts generate pngs that are too small when using Inkscape 0.92 or later due to Inkscape changing its default dpi from 90 to 96. Changed script to use width and height flags as they produce png files with correct dimensions on all Inkscape versions.
BUG: 453365
This reverts commit 3fe906b0bc.
Despite the attempt to hack dynamically swapping metrics
into working by simulating a StyleChanged event, this
doesn't work with many controls and ends up just causing
layout bugs and inconsistencies, and we agreed on
preferring consistent but undynamic vs dynamic and inconsistent.
Since data view headers are not the content the user is trying
to peruse, having them be the same size as an actual cell of data
(or larger) doesn't really make sense.
Instead, they can be made smaller, which gives more room to the
content the user is looking for, and helps make the distinction
between header/data more visible.
- buttons now flatten
- default buttons don't show their blue colour, because, they aren't the
button that'll get triggered on enter if their window isn't active
l10n daemon script
Jonathan Esk-Riddell
Mazhar Hussain
Ingo Klöcker
David Edmundson
ivan tkachenko
No Names
Jan Blackquill
Friedrich W. H. Kossebau
Niccolò Venerandi
Fushan Wen
Chris Chris
Alexander Lohnau
Marco Martin
Nicolas Fella