Since some people apparently liked the old behavior of moving minimized
windows to the end of the focus chain, let's let them have it if they
set a hidden config option:
`MoveMinimizedWindowsToEndOfTabBoxFocusChain=true` in the `[TabBox]` group
of the kwinrc file.
We can add a UI for it later if needed.
BUG: 427840
FIXED-IN: 5.21
Surface ids are not unique across clients. If the underlying surface of
an XdgToplevelClient is replaced with an Xwayland's surface, you may see
weird results such as a desktop window having the contents of an X11
window or even worse a crash.
BUG: 428680
Listen to logind for resume notification and turn the outputs on when it
happens, much like we do when pressing a key.
This way laptops come back on when the lid opens.
BUG: 428424
Once the main surface has been unmapped, we are no longer interested in
any changes that indicate that the window quads cache should be discarded
This also fixes a bug where the scene holds a subsurface monitor object
even after the associated window has been destroyed.
QGraphicsRotation and Scale are QObject wrappers. It's not useful in
data structures where we're creating mulitple of these every frame. It's
large enough to appear in hotspot as taking over 1% of a regular frame.
We don't even use the QGraphicsRotation mapping inside scene for a
reason, so it's not giving us much.
It's technically an API break in libkwineffects. Pragamatically no-one
would use these. We also lose QGraphicsScale's origin, but we never
exposed this in PaintData's public header.
Since commit commits.kde.org/plasma-workspace/378309e666f52fc436c75648a9e6ad7d5dcbacdf
ksmserver sets a desktopname when restoring applications. This causes the effect
to draw above the splash windows while no cursor is visible.
We want to multiply the width/height by scale weather or not we are
using GLES or not, otherwise this will only provide part of screen when
used with e.g fullscreen screenshot.
By default, the rules list moves to the hightlighted item
(the one being edited) with a constant velocity. This can
be too slow when the list contains hundreds of items.
By setting `highlightMoveDuration` we set a maximum limit
for this animation.
BUG: 428139
If window thumbnails have to be downscaled, it's up to the application
what filter must be used. Also, we don't really use the lanczos filter
because both x and y scale factors are 1.
This is unnecesary and also causes a bug, overwriting
previously set properties with the new detected values
when calling for the menu `Edit window properties`.
We need to emit DBus signal on every layout change - explicit(keyboard shortcut, layout applet click)
and implicit(focus window with different layout).
Otherwise, external layout applet might not get updated.
DIGEST:
BUG: 426900
The following click behaviors are defined:
* Switch desktop and activate window [default]
* Switch desktop only
The former emulates the previous default of activating clicked windows
using the Present Windows effect. The latter introduces a new mode where
the clicked window is not activated, allowing the user to select a
virtual desktop without worrying about disrupting the last active
window.
The configuration toggle that controlled the use of the Present Windows
effect has been subsumed into the first click behavior, i.e., if the
effect is enabled, it will be implicitly triggered.
AnimationEffect schedules repaints in postPaintWindow() and performs
cleanup in preScreenPaint(). With the X11-style rendering, this doesn't
have any issues, scheduled repaints will be reset during the next
compositing cycle.
But with per screen rendering, we might hit the following case
- Paint screen 0
- Reset scheduled repaints
- AnimationEffect::prePaintScreen(): update the timeline
- AnimationEffect::postPaintScreen(): schedule a repaint
- Paint screen 1
- Reset scheduled repaints
- AnimationEffect::prePaintScreen(): destroy the animation
- AnimationEffect::postPaintScreen(): no repaint is scheduled
- Return to the event loop
In this scenario, the repaint region scheduled by AnimationEffect will
be lost when compositing is performed on screen 1.
There is no any other way to fix this issue but maintain repaint regions
per each individual screen if per screen rendering is enabled.
BUG: 428439
They would override KScreen in case we were using a dock station that
brings 2 displays.
We'd get:
- udev: event for the first hotplughed screen
- kwin: process all screens properly (both)
- kscreen: would offer the right configuration for such displays
- udev: process the event for the second hotplug udev event
- kwin: restore the configuration
- kscreen: would think this is a conscious decision and embrace it as a
configuration
With this change we are only re-reading the configuration in case the
outputs changed.
At the moment, despite the protocol supporting it, we were not feeding
the EDIDs. KScreen was falling back to the output name so it didn't fail
horribly but it's still a good idea to provide all the data.
Prefer replacing then deleting the selection to the other way around.
This way less events need to be reported and the clipboard manager
doesn't get confused.
At the moment there was a race condition when putting something into the
keyboard from XWayland apps. The clipboard manager would announce a new
thing before we'd submitted it all resulting in a broken state.
This change detects when it's fetching and will only refresh the source
after everything has been sent.
BUG: 424754
CCBUG: 412350
