This adds an option to set the accent color from the current wallpaper.
The way it works is that it exposes some DBus calls; if a wallpaper plugin
supports wallpaper accent colors then it should say so by this DBus call
when starting up and also should say which wallpaper is being currently
used (for the purpose of extracting an accent color from it) or set an
accent color itself. After that it should keep declaring the wallpaper or
set accent color whenever wallpaper changes or whenever the plugin author
thinks it is appropriate to say so.
There is already an implementation of the color extracting algorithm which
the plugin can either use, or else set whatever accent color it wants. The
necessary DBus calls for the official image and wallpaper plugin are
implemented, so they should work out of the box.
BUG: 444676
FIXED-IN: 5.25
Because of the wallpaper interface from plasma-frameworks, we can not change
this during KF5. However we can use QQmlPropertyMap as the type, when we do not care
about the KConfig specific bits. Both KConfigPropertyMap and KDeclarative::ConfigPropertyMap
extend from this class.
Task: https://phabricator.kde.org/T12126
745e2c0828 made DesktopView set clear
color to "black" so the compositor could avoid overdraw and thus
optimizing rendering. In the perfect world, such a change would create
no regressions, but for some reason, it made panels lose alpha channel
on X11.
That makes absolutely no any sense. DesktopView and PanelView are two
totally different code paths. So changes in DesktopView should not
affect the PanelView. This looks like a QtXCB bug.
Ideally, we should add workarounds only after finding what creates a
problem, but this one is particularly hard because many people who have
tried to reproduce that issue weren't successful. Somebody who can
reproduce the issue would have to be able to build Qt from source code
and add qDebug()s. These requirements are too steep, thus adding a
platform check seems like the best option at the moment.
BUG: 450672
index desktop views by qscreen instead of id, making ScreenPool
the single source of truth for the mapping between screen names
and ids. This is less error prone and easier to consistency check
(if view->screenToFollow() is ever different to its has key it will
assert)
The whole logic of screen management is moved to ScreenPool.
ShellCorona will have to never call QGuiApp->screens, but only trust what ScreenPool it's telling it
Also adds an autotests on screenpool which makes a fake wayland server which sends screen added/removed/changed events
On multiscreen (seems to happen only on X11 so far) when screen are
added and moved, sometimes the panel gets moved by the window manager
ending up out of screen boundaries, leaving a screen without panel
a common scenario is:
laptop with external screen connected, panel on internal screen,
close the lid, everything gets moved to the external screen,
the panel will stay out of screen boundaries, but the panel struts are correct
CCBUG:438114
Since the DesktopView has "transparent" clear color, it will allocate a
buffer with an alpha channel and QtWayland won't be able to set an
opaque region. This change sets the clear color of DesktopView to "black"
so overdraw can be fixed in kwin and to improve render performance on
wayland.
Fushan Wen
Volker Krause
Alexander Lohnau
Niccolò Venerandi
Laurent Montel
l10n daemon script
Tanbir Jishan
Aleix Pol
Oleg Solovyov
Marco Martin
Vlad Zahorodnii