--m_iconSize for standalone buttons can be changed
dynamically based on user or container preferences.
Such an example could be the window buttons applet
that is resizing its buttons based on panel thickness
or when the applet is on the desktop and the user
resizes it. Previous implementation was failing
because even though m_iconSize was set as NULL for
StandAlone buttons, on the first painting m_iconSize
was set based on Button::geometry(). This of course
was failing because the Button::geometry() could change
afterwards and painting was not considering it to
calculate m_iconSize again.
QPainter's auto-scaling is prone to off-by-one rounding errors and draws on
fractional coordinates. With this change, we paint on a 1x DPR QPainter and
scale the shadow offset and strength manually based on DPR.
This resolves an issue with resulting in seams on the right and bottom
edges of a menu due to shadow boundaries being off-by-one.
BUG: 418166
v2: remove unrelated formatting changes
v3:
- move the DPR helper to ShadowHelper
- retrieve the DPR from the widget instead of the global QGuiApplication
- added BUG reference
This reverts commit 916cc11f35.
I'm reverting the reversion on master because the reason for reverting
the original commit seems to have been based purely on an assumption
about what the patch did rather than testing anything.
There are 2 parts that contain the bulk of the code in this patch.
Style::event() is used to apply the QFocusFrame to a widget when it gets
focus with a keyboard input related focus reason. If the focused widget
has a focusProxy, this makes sure the QFocusFrame is applied to the
focusProxy instead.
Style::drawFocusFrame() is mostly what you'd expect. It draws a focus
frame based on the type of widget the QFocusFrame was applied to. I had
to do a workaround for QFocusFrame not fully repainting ouside the
bounds of QSliders and QDials when the handle moves though. What I do is
check if `_focusFrame` is defined and then `_focusFrame->update()`.
BUG: 443469
This prevents most buttons outside of QDialogButtonBoxes from getting
the default button visuals/behavior.
Internally, QPushButton::autoDefault can be explicitly on, explicitly
off, or automatic (enabled if in a QDialog).
If autoDefault is explicitly on and not in a dialog, or on/automatic in
a dialog and has a QDialogButtonBox parent, explicitly enable
autoDefault, else explicitly disable autoDefault.
If someone explicitly enabled autoDefault outside of a QDialog, they
probably had a reason to do that, so we'll avoid interfering with that
if we can. Unfortunately, there is no way to detect if autoDefault was
explicitly enabled inside of a QDialog, so that might mess with a small
minority of applications.
The previous way it was painted was kind of messy in the sense that
other parts overlapped with the active tab when they shouldn't have or
didn't overlap enough like with the highlight. There were also some
painting artifacts that were just weird and are now gone.
This is no longer the default color scheme; Breeze Light is. But being
named "Breeze" implies that is is the default or at least the base,
rather than simply one of several variants. Let's rename it to "Breeze
Classic" to make it follow the pattern and avoid subtly giving it more
textual weight.
This color scheme is a misnomer, and does not actually offer higher
contrast than other color schemes. In fact its contrast is generally
worse. As a result it hurts more than it helps. A true "high contrast
mode" would require changes to the QStyle to make UI elements larger or
change their borders to actually offer an improvement for people who
need higher contrast than what is offered by Breeze and Breeze Dark.
Accordingly, let's delete this color scheme and migrate current users to
Breeze Dark, which is the shipped theme that looks closest to it, and
has *better* contrast in many ways.
BUG: 352506
BUG: 442286
FIXED-IN: 5.24
These colors were previously using the same values as in other contexts,
but this was not appropriate for the Selection set, because contrast and
readability were low. This commit addresses that by making the colors
darker just for the Selection color set. Now they are much more
readable.
This change is made to all four of the Breeze* color schemes, as they
all suffered from the issue.
BUG: 406239
FIXED-IN: 5.23
This option is off by default and has been for several years, after it
was briefly turned on by default and proved to be unpopular with users,
generating many complaints and bug reports. The line uses a semantically
inappropriate highlight color which is far too visually bright, and it
doesn't look good with any of our header-color-using color schemes.
Arguably it never looked good with older color schemes where the titlebar
and window background use different colors either. Let's remove this
option.
BUG: 427422
FIXED-IN: 5.24
A style shouldn't mess with clients like this, especially
if it behaves different from literally any other QStyle out
there, and breaks decades of muscle memory.
This partially reverts 00693ee5e7
BUG: 438994
- Use a very slight gradient
- Use blue for pressed state
- Make shadow vertical, not diagonal
- Use gray for checked buttons
Some people thought blue checked buttons were pretty, but some people
thought they demanded too much attention. In order to merge the changes
faster, I switched to using gray for checked buttons.
Michail Vourlakos
l10n daemon script
Tatsuyuki Ishi
Jonathan Riddell
Noah Davis
Jan Blackquill
Nicolas Fella
Nate Graham
Ismael Asensio
Alexander Lohnau
Kai Uwe Broulik
Niccolò Venerandi