BUG: 444203

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

It's time. We actually relied on this to export colors, but handle
this now in startplasma.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Jan Blackquill authored Sep 21, 2021 and Nate Graham committed Nov 09, 2021

BUG: 369016

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

--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.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Tatsuyuki Ishi authored Oct 01, 2021 and Noah Davis committed Oct 11, 2021

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

GIT_SILENT

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

This reverts commit 916cc11f.

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.

This reverts commit d4803e4a.
This commit reintroduces the problem that its precursor was reverted
for and merged without adequate time for review.

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.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

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.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

This will prevent them from drifting out of sync over time.

Ismael Asensio authored Sep 23, 2021 and Nate Graham committed Sep 24, 2021

Removing this turned out to cause a small visual glitch in the
settings window for some apps

BUG: 442860
FIXED-IN: 5.23

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

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

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Looks like an oversight at some point in the last, as all three other
Breeze* color schemes have the correct value here.

BUG: 419960
FIXED-IN: 5.23

Looks like an oversight at some point in the last, as all three other
Breeze* color schemes have the correct value here.

BUG: 442478
FIXED-IN: 5.23

Task: https://phabricator.kde.org/T14744

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