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
This reverts commit 27bcd1be9c.
The change in question has the potential to introduce regressions with
alternative icon themes, and in retrospect is not necessary for the
feature it was created in support of (https://phabricator.kde.org/D19311)
Summary:
While dimensions of QScreen are in logical pixels, the origin is not.
As result, computed native coordinates are incorrect on high dpi.
Test Plan:
Drag a window by empty area on a multiple monitor setup (with High DPI),
neither cursor nor windows should "jump."
Reviewers: #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D20182
Summary:
Changes the drawing of inline indicators with QToolButtons so that it
is drawn as a small arrow in the lower right corner.
Test Plan: Show QToolButton with Menu and PopupDelay enabled
Reviewers: #vdg, #breeze, ngraham
Reviewed By: #vdg, #breeze, ngraham
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D19890
Summary: Before, shadow size doubled with each new size until Very Large and the smaller shadows were more transparent than the larger shadows. Now shadow size increases linearly and smaller shadows start with more opacity so that they don't become nearly invisible. The new shadows should look better on cheap displays.
Test Plan:
Before
======
Small: {F6622411}
{F6632347}
Medium: {F6622412}
{F6632346}
Large: {F6622413}
{F6632344}
Very Large: {F6622415}
{F6632341}
After
=====
Small: {F6624603}
{F6632334}
Medium: {F6624606}
{F6632335}
Large: {F6624608}
{F6632336}
Very Large: {F6624612}
{F6632337}
Reviewers: #vdg, #breeze, ngraham, rooty
Reviewed By: #vdg, #breeze, ngraham, rooty
Subscribers: filipf, ngraham, zzag, rooty, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D19148
In widgets:
* windowHandle() only works for top level widgets (windows), so we need to first get the actual window() as windowHandle() is always
nullptr for controls like ComboBox
In QtQuick Controls:
* we would just blow up for accessing widget which is null here. Use the QQuickWindow of the QQuickItem, if any. Given how long this
went unnoticed shows that Qt *never* ever had icons working in ComboBoxes in QtQuick...
Differential Revision: https://phabricator.kde.org/D18655
Summary:
Creation of shadows (especially for "Large" and "Very large" sizes) is
a computation expensive task because we have to blur alpha channel of a
shadow texture (which then will be tinted with desired shadow color).
Currently, we use the following approach:
* for blur radius less than 64, use naive 2-pass algorithm;
* for blur radius greater than or equal to 64, use FFT.
Even though the FFT approach is doing its the best, it still takes
impresive amount of time to blur the alpha channel.
What makes things even worse is that while we're blurring the alpha
channel, we're blocking the main thread of KWin (decorations are not
rendered in their own thread). This can result in frame drops (2 or 3
frames, something like that).
So, the only viable alternative is to use an approximation of the Gaussian
blur. As such an approximation, I picked the box blur because it's quite
simple, it's fast, and it takes small amount of iterations to have something
similar to the true Gaussian blur.
In general, there are no big differences between true gaussian shadows
and approximated shadows:
Before:
{F6312610}
After:
{F6312613}
Before:
{F6280935}
After:
{F6312608}
As a win, it takes much less time to generate decoration shadows.
Reviewers: #kwin, #plasma, #breeze, #vdg, ngraham
Reviewed By: #breeze, #vdg, ngraham
Subscribers: cfeck, ngraham, abetts, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D15514
Summary:
For a mouse users have the precision that if they clicked in an empty
area they want to perform some action.
For touch and tablets that isn't necessarily true.
From Boud in a kwin report: "The drag the window by empty areas is a
nasty one as well, especially when you're using a pen."
Change needs to happen in oxygen too
Test Plan:
Moved window using sidebar of kate with mouse
Couldn't drag it with a pen
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D15942
It is QtQuick_FOUND, not Qt_Quick_FOUND. This broke all special-casings for QtQuick,
such as "drag on empty area" in QtQuick windows and ComboBox popups.
BUG: 398663
FIXED-IN: 5.14.0
Differential Revision: https://phabricator.kde.org/D15568
Summary: I tested a bit of code with -02 to measure the speed gains of using a std::initializer_list over appending to a temporary and appending to temporary is around 50% slower, so I removed all the code that appened to temporaries for a initializer list in breeze.
Reviewers: #breeze, #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: davidedmundson, ngraham, zzag, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D13591
Summary:
libbreezecommon is not meant to be used outside of breeze (it can't, no headers
are installed) so the .so link is not necessary.
Additionally, rename libbreezecommon.so.5 to libbreezecommon5.so.5 for symmetry
with libbreezecommon4.so.5.
Test Plan: Built and installed it - still works.
Reviewers: #breeze, zzag
Reviewed By: zzag
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D14599