Changed handle thickness from 10px to 8px. This makes the spacing around
the handle look more consistent. Visually, there was 5px of empty space
on each side, now there is 6px of empty space on each side.
(cherry picked from commit 2f92640270)
base_size.jpg/vertical_base_size.jpg are not considered by Plasma as they
don't follow the WIDTHxHEIGHT pattern. Not installing those reduces the
installed size from 39M to 6.7M!
(cherry picked from commit c93630f9b7)
Assigning a menu with instant popup mode to an action gives it
excessive left padding. Removing the extra margin fixes it.
BUG: 447288
(cherry picked from commit 47a015cde2)
Under Window Decorations, the option "Draw a circle around close button"
is unchecked by default. This normally applies to both window and tab close buttons, but tab buttons permanently had the circle visible because this boolean was incorrect.
This made it impossible for the user to disable this style via GUI. `OutlineCloseButton=false` had to be explicitly added to `~/.config/breezerc`.
Fixes a regression that started in the 5.23 cycle.
BUG: 448122
FIXED-IN: 5.24
(cherry picked from commit f2d33bd33e)
We will have to revert the spinbox style to the old style for 5.24. We
had to revert the style for 5.23 on the 5.23 branch just before release
to prevent users from facing issues and we still haven't figured out an
acceptable way to make the new style work with all apps. Might as well
revert it on master at this point.
Qt Widgets apps and even some Qt Widget APIs (such as stylesheets) are
designed for spinboxes that stack 2 buttons vertically, not horizontally
on either side of the field. Unless Qt adds a way to specify whether or
not to use the traditional spinbox layout as a Qt Widget API, Qt Widgets
apps will just have to use the traditional style forever.
previous discussion: https://invent.kde.org/plasma/breeze/-/merge_requests/142
This restores the spacing for separators that was lost since around
Plasma 5.20.
Long menus can be difficult to scan and overwhelming when all items are
clumped together with no additional spacing. This balances the
margins/padding similar to how they were pre-5.20.
The button coloration agreed to in the Breeze Evolution work wound up
reverted in c4f93a4be5 because we were
previously tinting the button color in the QStyle rather than changing
the color scheme colors instead. The effect works for the dark color
scheme, but not the light one, so we need to manually lighten the button
color a bit there. This commit does that, restoring the intended button
coloration for the Breeze Light color schemes as per the ongoing Breeze
Evolution work.
The current code checks for !complexOption, but then continues to
de-reference it in the second clause of the statement leading to an
inveitable crash.
I assume it's meant to be an `or` for the latter part of the statement
to make sense.
--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.
David Faure
Bharadwaj Raju
l10n daemon script
Noah Davis
Fabian Vogt
Fushan Wen
Luke Horwell
Jonathan Riddell
Volker Krause
Nate Graham
David Edmundson
Nicolas Fella
S. Christian Collins
David Redondo
Jan Blackquill
Michail Vourlakos
Tatsuyuki Ishi