otherwise we can dbus invoke with the wrong environment. specifically
this happens with the latest qtbase changes that introduced color
picking support on wayland. when we start a qguiapplication with
incomplete environment that dbus invokes the xdg-portal system and that
in turn has an incomplete environment resulting in theming and the likes
not properly applying because the portal doesn't know that it runs
inside a plasma session.
2dc083df00
BUG: 458865
(cherry picked from commit 9bf0e56da8)
The intention of this code appears to be finding system tray applets, since the systemtray is a containment within another applet/containment
However the code causes an infinit recursion since we are calling addContainment on the same containment again
The recursion also is unnecessary since corona->containments() already lists the system tray containment, so we don't need to find it by recursing through the panel's children
(cherry picked from commit c7ba560cca)
When using a language that's wordier than English and this label becomes
a two-line string, currently the layout breaks and the string overflows
because the Label item that draws it has no maximum height and elision
mode set.
This commit fixes that by setting them accordingly, and also using a
standard icon size for the icon so that there's actually enough room for
two lines of text.
BUG: 458614
FIXED-IN: 5.24.7
(cherry picked from commit 0dad5f0789)
Track the selected GTK theme in the model only. This fixes setting to default when the GTK pages was never opened
Override isSaveNeeded instead of calling setNeedsSave, this fixes the apply button enablement
(cherry picked from commit 0536cf4140)
The GTK theme name is not managed by KConfigXT, we need to manually track that when determining whether the Defaults button is enabled
BUG: 458292
(cherry picked from commit 05f21f51ba)
ba44b69abf added logic to handle apps that
use an absolute path in their .desktop file to define their icon, which
works. However in the process it introduced a subtle bug: if the icon is
not an absolute path and it's just a normal icon name, when
QFileInfo::exists() checks for the existence of that string, it will
treat it as a relative file path and therefore look for it in the
current working directory, which is typically the user's homedir. If it
finds something, it will go down the wrong code path and end up
returning a blank QIcon. This can be verified by adding a folder with
the name of an app icon into ~ and restarting plasmashell; that app in
Kickoff will have a blank icon.
To fix this, the icon loading code now first checks whether the icon
returned by m_service->icon() is actually an absolute path. If not, it
skips the logic to look for it on disk and goes straight to the
codepath that looks for an icon with that name in the icon theme.
To minimize disk reads, it checks for absolute-file-path-ness by
inspecting the string returned by m_service->icon() rather than using
QFileInfo::isAbsolute(), because this is a hot code path and most icons
will not have relative paths, so checking the disk for every one of
them would be a waste of resources.
BUG: 457965
FIXED-IN: 5.24.7
(cherry picked from commit 57d55e386a)
Alternatively we require to pass an absolute path which is more
cumbersome than one would want.
(cherry picked from commit 6ba01a5543)
Note: without this cherry-pick the fix for kcm_mouse in
KeyboardDaemon::configureMouse was incomplete.
CCBUG: 435113
Currently, the progress indicator is normally displayed only if the DPI is a
multiple of 100; at other DPI values it's almost invisible or not visible at
all. This commit fixes that issue.
BUG: 435004
FIXED-IN: 5.24.7
(cherry picked from commit b5f903862e)
Max and min are calculated from two completely different sources.
There's scope for them to not be the expected way round.
We have an assert reported on this line due to a subtle qBound ->
std::clamp porting difference on GCC with debug flags on.
BUG: 454064
(cherry picked from commit 449ae169d8)
On Wayland, the primary screen notification and
QGuiApplication::screenAdded signals are desync. The primary output
watcher addresses that by emitting its primaryOutputNameChanged() signal
when the corresponding QGuiApplication::screenAdded() signal is emitted.
However, since the primary output watcher processes the screenAdded
signal before ScreenPool, it can emit the
ScreenPool::primaryScreenChanged signal before ScreenPool::screenAdded
signal that can confuse the ShellCorona.
(cherry picked from commit bb822a3359)
window() may be null. We check for that, but 5a3ef9e825 introduced code that uses window() before the check.
Move the check before the relevant code to fix that
BUG: 456094
BUG: 457690
While we indeed write both with KConfig::Notify flag interested
processes might only listen to the scheme change instead of
every color scheme group. When they react to the scheme change
the colors have not yet changed.
The colors kcm also does it in this order.
BUG:421745
FIXED-IN:5.24.7
(cherry picked from commit 9a77503f0b)
Make sure the location is set before showing the window to ensure
the first appearance is animated correctly, too.
BUG: 447096
(cherry picked from commit 5bc7efd0d9)
In the config dialog of slideshow wallpaper, the first image is always in a "current selected" state (thick, deep blue border). And it can't change with neither mouse click or keyboard.
Slideshow has no such thing as "current", so this effect should be removed.
BUG: 457327

(cherry picked from commit 01defdb573)
Given that the wayland protocol does not have window positions a recent
change to Qt development branch avoids having a mismatch of positions
and tells client code the window is at the topleft of the screen. This
fixes multiple bugs.
Unfortuantely this breaks a few usages within plasma where a
side-channel sends that absolute positional information over a bespoke
protocol. Currently we proxy this all through QWindow geometry where the
new Qt behaviour will throw is askew.
Whilst our longterm plans are to find future options away from the
plasmashell protocol we may as well have our Qt6
build work given the patch is trivial and harmless.
It also allows for potential backporting if our software is
already secured against issues.
(cherry picked from commit 1be046edd455969b74417ded6871d25eba8a1112)
Test Plan:
Open Krunner and type ?
Scroll though the list of results until one has a configure button
Click that button and check if systemsettings opens and the runner's KCM is opened
(cherry picked from commit 65dbd95a96)
Having the right url is needed for drag and drop to work
For the recentdocuments runner we can just take the result
For the services runner the result is of the form "applications:org.kde.foo.desktop", so extract the service name from that
BUG: 456984