There was a pressed appearance for unchecked checkboxes and radio
buttons, but we were missing one for their checked states. This
commit simply adds the same effect: a slight and subtle darkening
while pressed.
BUG: 451428
FIXED-IN: 5.26
The Breeze implementation is older than qqc2-desktop-style framework,
and historically it used to use different base class. Times has
changed, along with base classes; but Breeze code did not -- instead
the problem was workarounded on a org.kde.desktop side first with a
dummy Timer that called updateItem(), then through more sophisticated
QtQuick Animations types (which delivered smoother results thanks to
being bound to refresh rate of a screen).
While this patch fixes the problem, it seems like a better solution
should be possible or more cleanup opportunities are available:
1. no other breeze animations invoke methods through QMetaObject system;
2. why and how an object would be something other than KQuickStyleItem?
Before that, the values were hardcoded (i.e. 16 for non-tablet mode
and 22 for tablet mode). Now, the value for non-tablet mode is taken
from the system, and the value for tablet mode is one step bigger.
BUG: 455513
FIXED-IN: 5.25.5
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.
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
Now interactive UI elements get bigger when in Tablet mode, and return
to normal size when out of it. This is automatic, and currently there
is no UI to manually control it.
Sending a stylechanged event makes everything to be reevaluated but
the style instance doesn't get actually reloaded, so this is still
manageable, resource-wise.
CCBUG: 418904
Showing focus/hover/etc. often looks strange/inconsistent without frames
on all sides, so if we're drawing on frames other than all sides, don't
show those states. It's also more consistent with the style we're trying
to emulate, which doesn't show focus/hover on separator lines between
views.
This fixes the contrast of tabs on dark themes by using
a darkening factor on the Window colour, adjusted for
whether it's light or dark, instead of using the Shadow
colour for both light and dark themes.
BUG: 438627
FIXED-IN: 5.25
Don't blend window background (default white) with selected text color
(also white), as this results in unreadable combinations. Instead, blend
it with the normal color.
BUG: 438964
FIXED-IN: 5.24.2
This prevents situations where menus take up excessive
amounts of the screen's area by overflowing into columns
instead of scrolling. Also matches our QtQuick behaviour.
BUG: 54716
FIXED-IN: 5.25
If we're changing the font size when painting we need to change the
fontSize when calculating the contents size too otherwise you end up
with things that don't fit
BUGS: 450333