GitLab

While the SplitterProxy is active, it intercepts all relevant events, so that
the underlying widget still thinks it's in the same "on splitter" state. When
the SplitterProxy is left, the underlying widget is sent a HoverLeave/HoverMove
event to make it aware of the new current cursor position. Without this, it
doesn't know that it's not supposed to be in the "on splitter" state, and when
it regains focus it just re-activates the SplitterProxy at the current cursor
position.

This was broken by accident in d201a1f1 ("Fix SplitterProxy not clearing
when above another QSplitterHandle"), which moved the hide() call past the
call to QCoreApplication::sendEvent. Previously that made isVisible() false,
which also prevented the interception of the HoverLeave/HoverMove events.

BUG: 436473


(cherry picked from commit f99b7ef6)

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"

When two SplitterHandles are next to each other, like at the intersection of a
horizontal and vertical splitter (|-), then it's possible that hiding the proxy
of one of those handles causes the other handle to gain focus immediately,
which activates the SplitterProxy again. Before this patch, it would then
continue clearing after reenabling itself, leading to an inconsistent state.

BUG: 431921
(cherry picked from commit d201a1f1)

It clears the splitter when enabling it, that seems wrong.
Despite this bug, it still mostly worked before because the eventFilter checked
for _enabled anyway.

(cherry picked from commit 4b10546c)

GIT_SILENT

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"

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"

GIT_SILENT

GIT_SILENT

Cherry-picked from 7b336d45.

Paul McAuley authored Mar 16, 2020 and Nate Graham committed Mar 16, 2020

Fix Defaults not being set properly in Breeze window decoration settings for 'Draw a circle around close button'

Summary: This fixes a small bug in the Breeze window decoration settings where clicking on 'Defaults' did nothing to change 'Draw a circle around close button' . This patch now causes 'Draw a circle around close button' to default correctly.

Reviewers: #breeze, hpereiradacosta

Reviewed By: hpereiradacosta

Subscribers: ngraham, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D28087

GIT_SILENT

GIT_SILENT

GIT_SILENT

Guilherme Silva authored Feb 17, 2020 and Nate Graham committed Feb 17, 2020

Summary: The Cursor Specification doesn't even mention these two, but Chromium-based apps search for them using a different name than ours, so it wouldn't hurt to symlink them.

Test Plan:
This can be tested on any webpage using either `cursor: grab` or `cursor: grabbing` CSS rule. But here's a page where you can easily test them:

http://elektronotdienst-nuernberg.de/bugs/cursor.html

Reviewers: #breeze, broulik, ngraham

Reviewed By: #breeze, broulik, ngraham

Subscribers: ngraham, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D27424

GIT_SILENT

Summary:
Due to filesize concerns, we optimized the Volna wallpaper to be JPEG compressed at 90% quality.

JPEGs seems like the right way to go, but at 90% there is a noticeable loss of sharpness and JPEG artifacts appear, both of which are more prominent the smaller the resolution.

I used the same tool (squoosh) to generate more high quality JPEGs, paying attention to how each resolution responded to a certain quality setting.

In the end I had to use values between 94 and 98 in order to ensure there is no noticeable difference with the original PNGs.

This brings up the total file size to 17.4 MiB, which I think is still fine, especially given that this is our default wallpaper for an LTS release.

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D27045

This reverts commit 8f4ea0a9.

It didn't work. :( We will need to find another way.

Summary:
Because of the issue described in T12611, changing the filetype of the Next wallpaper is
problematic and will cause a black screen on upgrade.

This terrible horrible patch works around the issue by using the .png filename extension
even though this is not accurate. That way, the file names are the same as the old
versions of the Next wallpaper and will be loaded correctly. Using the wrong filename
extension does not actually cause any problems, it's just inaccurate. a `README` file is
placed next to the images to explain this.

I'm sorry.

Long-term, we should investigate T12611.

Test Plan:
Have previous Next wallpaper (Ice Cold) installed
Replace it on disk with Volna in original JPEG form
restart plasmashell -> black screen

Try the above again with this patch
restart plasmashell -> new wallpaper visible

Reviewers: davidedmundson, #plasma, ognarb

Reviewed By: ognarb

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D26972

Summary: Volna won the wallpaper competition, so time to add it to Breeze as the new default!

Test Plan: Apply patch, compile, and restart plasmashell

Reviewers: #vdg, #plasma, davidedmundson

Reviewed By: #plasma, davidedmundson

Subscribers: raveomelette, IlyaBizyaev, Luwx, ndavis, broulik, rikmills, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D26953

They are "up for discussion" [1] but seem to be used by e.g. Chrome.

[1] https://www.freedesktop.org/wiki/Specifications/cursor-spec/

Differential Revision: https://phabricator.kde.org/D26726

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

GIT_SILENT

Summary:
KWindowEffects provides a platform-independent API for enabling blur,
which requires neither Xlib nor XCB.

Test Plan: Compiles.

Reviewers: #plasma, davidedmundson

Reviewed By: #plasma, davidedmundson

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D26631

Hugo Pereira Da Costa said Text is better because scrollbar are usually
rendered over item views.

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

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"