Summary:
center only the drawing of the components but never modify the
subcontrolrects (and hit targets)
BUG: 416348
FIXED-IN: 5.18.0
Test Plan:
now the handle activates immediately without one single pixel
margin
Reviewers: #vdg, hpereiradacosta, ndavis
Reviewed By: #vdg, ndavis
Subscribers: ngraham, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D26783
Summary:
This look makes listviews look way better, not having the selected
items look truncated into nothingness.
Always display "big" handles, due to the numerous complaints of the slim handles not being obvious
Test Plan:
Before:
{F7882628}
After:
{F7882624}
Reviewers: #plasma, #breeze, #vdg, ngraham, hpereiradacosta
Reviewed By: #vdg, ngraham, hpereiradacosta
Subscribers: ndavis, ahiemstra, hpereiradacosta, mthw, plasma-devel
Tags: #plasma
Maniphest Tasks: T9126
Differential Revision: https://phabricator.kde.org/D26655
Summary:
Second part of D26655, removes the thin scrollbar and makes it always thick
to implement the desired design
BUG: 396747
FIXED-IN: 5.18.0
Test Plan: {F7884060}
Reviewers: #plasma, #vdg, #breeze, ngraham, ndavis
Reviewed By: #vdg, #breeze, ngraham, ndavis
Subscribers: plasma-devel
Tags: #plasma
Maniphest Tasks: T9126
Differential Revision: https://phabricator.kde.org/D26685
Summary: If the widget has an item view parent, use the View Background color. Otherwise, use Window Background.
Test Plan: {F7881597, size=full}
Reviewers: #vdg, #breeze, hpereiradacosta, ngraham
Reviewed By: #vdg, hpereiradacosta
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D26639
Summary:
QQC2/Kirigami checkboxes and radio buttons can turn invisible when rendered over a selected item because their background isn't rendered and they don't have any hacks to detect when they're being rendered over a selected list item.
While the problem isn't technically a Breeze QStyle problem and a hack could be made for QQC2/Kirigami, I don't think there's any great style benefit to not rendering a background for the checkbox. I suppose there is a performance benefit to not rendering a checkbox background except for when the background is different from normal. In my testing with GammaRay's paint analyzer, the checkbox background has a cost less than 5%. The radiobutton background has a cost of 15-20% (maybe it can be improved?).
Reviewers: #vdg, #breeze, #plasma, hpereiradacosta, ngraham
Reviewed By: #vdg, hpereiradacosta, ngraham
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D26572
Summary: This patch reduces the amount of duplicate code and makes every part of the helper functions use the correct frame radius.
Reviewers: #breeze, #plasma, hpereiradacosta, ngraham
Reviewed By: hpereiradacosta
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D26225
Summary:
The following functions have deprecation warnings: QTime::start(), QTime::restart(), QTime::elapsed() and recommend that QElapsedTimer be used instead of QTime.
_clock.isNull() had to be changed to !_clock.isValid() since QElapsedTimer does not have isNull().
QTime::isNull() is also invalid, so behavior shouldn't change.
Reviewers: #breeze, #plasma, hpereiradacosta
Reviewed By: hpereiradacosta
Subscribers: hpereiradacosta, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D26268
Summary:
According to an article by @cfeck [1], QFontMetrics::width() gave the horizontal advance, which doesn't necessarily include every pixel that the text might use.
He suggested that boundingRect().width() might be what most people actually want.
- [1] https://kdepepo.wordpress.com/2019/08/05/about-deprecation-of-qfontmetricswidth/
Reviewers: #breeze, #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: hpereiradacosta, cfeck, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D26270
Summary:
The replaced numbers are directly related to the width of the pen.
This patch likely doesn't replace all of the numbers that could be replaced.
It just replaces the ones I'm currently certain of being related to pen width.
The goal is to make the code show the intent of the designer.
Reviewers: #breeze, #plasma, hpereiradacosta, ngraham
Reviewed By: #breeze, hpereiradacosta, ngraham
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D26217
Summary:
This reverts commit c9aa535863.
Also makes the small down arrow pixel perfect. I will make the other arrows pixel perfect in a separate patch.
After D19890 (27bcd1be9c) was reopened, there was some discussion about the reason it was reverted and the problems it introduced. It is possible that an icon could partially cover this arrow, but it seemed uncommon enough that ignoring the problem was deemed acceptable. The type of control that this arrow is used for is also pretty uncommon because it does not feel very good to use with a mouse or touchpad.
Reviewers: #vdg, #breeze, #plasma, hpereiradacosta, ngraham
Reviewed By: #vdg, #breeze, ngraham
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D26139
Summary:
This patch makes other helper functions reuse more code by calling these shadow rendering functions instead of defining their own shadows.
The shadows are perfectly shaped, tested up to 8x scaling.
Without this patch, the radius of the shadows for checkboxes is slighly too wide and there is a gap between the inside edge of the radio button shadow and the outside edge of the radio button.
Shadow rendering performance has also been improved a bit.
Test Plan:
run `QT_SCALE_FACTOR=8 oxygen-demo5` and examine the shadows. You can try higher scaling levels, but that's overkill.
8x scaling
before: {F7824689, size=full} {F7824691, size=full}
after: {F7824692, size=full} {F7824693, size=full}
Reviewers: #breeze, hpereiradacosta, #plasma
Reviewed By: hpereiradacosta
Subscribers: ngraham, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D26094
Summary:
Before this patch, the outline of the rubberband selection control was down and to the right half a pixel too far.
This wasn't visible at 1x scaling because of the lack of antialiasing, but resulted in the top/left being too thin and bottom/right being too thick on high DPI displays.
To fix the issue, I enabled antialiasing and moved all sides inwards by half a pixel so that the outline would be pixel perfect.
I also added a function to get a QRectF with the correct size and position for rectangles with pen strokes.
Test Plan:
- Open dolphin and make a selection with the mouse
- Go to a Folder View Plasma widget and make a selection with the mouse
2x scaling
before: {F7818498, size=full}
after: {F7818500, size=full}
3x scaling
before: {F7818484}
after: {F7818483}
Reviewers: #vdg, #breeze, #plasma, hpereiradacosta, broulik
Reviewed By: hpereiradacosta
Subscribers: broulik, plasma-devel
Tags: #plasma, #breeze, #vdg
Differential Revision: https://phabricator.kde.org/D26001
Summary:
Add some const & for things that return const & so there's no need to make a copy
Add a std::move for a thing that we pass by copy and it's just saved in another variable
Reviewers: zzag
Reviewed By: zzag
Subscribers: zzag, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D24614
Summary: It bothered me that the groove for dials doesn't match the maximum area that the contents can use.
Test Plan:
Old: {F7366118, size=full}
New: {F7366127, size=full}
Reviewers: #vdg, #breeze, ngraham
Reviewed By: #vdg, #breeze, ngraham
Subscribers: ngraham, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D24008
Summary:
This fixes the colors of things like context menus and application menus
T11124#193132
Test Plan:
Old:
{F7096221}
New:
{F7248348}
Reviewers: #vdg, #breeze
Subscribers: hpereiradacosta, mglb, ngraham, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D23170
Summary: Apparently, the code to adjust the rectangle when a menu is present is what was causing the problem. Also added an if statement to move the separator with the button when sunken.
Test Plan:
Old:
{F7248297, size=full}
{F7248298, size=full}
New:
{F7248300, size=full}
{F7248301, size=full}
Reviewers: #vdg, #breeze, ngraham
Reviewed By: #vdg, #breeze, ngraham
Subscribers: ngraham, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D23169
The constructor of QMouseEvent actually expects windowPos and/or screenPos but never globalPos.
By only supplying a localPos we have Qt figure it out correctly on its own.
Differential Revision: https://phabricator.kde.org/D22851
Summary:
Remove unneeded 1 pixel margin around side panels, namely QAbstractScrollArea with property _kde_side_panel_view set to true.
In order to be able to still draw a vertical line on the side of the list, a one pixel margin is kept, on this side only, using SE_FrameContent subelementRect
The viewport background is kept to QPalette::Base, as for regular lists.
The logic in polishScrollArea has been adjusted accordingly
Differential Revision: https://phabricator.kde.org/D22138
- removed useless "virtual" specifications
- removed useless destructors
- cleanup variable initializations
- moved protected methods as private when possible for better encapsulation
Summary:
Without this patch, changing the application color scheme from system
settings only affects some widgets. Notably, checkboxes highlighting
colors stays the old color, leading to a hodge-podge color scheme and
bad contrast on some items.
The breeze QStyle caches the colors read via KSharedConfig, so it needs
to re-read the configuration when the application color changes.
QApplication emits a signal (originating in KGlobalSettings), which we
can react to.
This fixes the coloring of various widgets in breeze right after color
changes.
BUG:408416
FIXED-IN: 5.16
Those I haven't tested, but look quite suspicious (so please re-test):
CCBUG:382505
CCBUG:355295
Test Plan:
1. open kcmshell5 colors
2. change to a theme with a different highlight color
3. apply
* without patch: checkbox in color KCM (and a whole lot of other
widgets all over the place) don't change colors
* with patch: colors change as expected
Reviewers: #plasma, broulik, sitter
Reviewed By: #plasma, broulik, sitter
Subscribers: sitter, cfeck, broulik, zzag, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D21646
Summary:
Without this patch, changing the application color scheme from system
settings only affects some widgets. Notably, checkboxes highlighting
colors stays the old color, leading to a hodge-podge color scheme and
bad contrast on some items.
The breeze QStyle caches the colors read via KSharedConfig, so it needs
to re-read the configuration when the application color changes.
QApplication emits a signal (originating in KGlobalSettings), which we
can react to.
This fixes the coloring of various widgets in breeze right after color
changes.
BUG:408416
FIXED-IN: 5.16
Those I haven't tested, but look quite suspicious (so please re-test):
CCBUG:382505
CCBUG:355295
Test Plan:
1. open kcmshell5 colors
2. change to a theme with a different highlight color
3. apply
* without patch: checkbox in color KCM (and a whole lot of other
widgets all over the place) don't change colors
* with patch: colors change as expected
Reviewers: #plasma, broulik, sitter
Reviewed By: #plasma, broulik, sitter
Subscribers: sitter, cfeck, broulik, zzag, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D21646