This fixes integration of the zoom effect with the blur effect and qtquick
effects such as overview or window view.
The main con of the proposed solution is that offscreen rendering can be
a bit overkill. But on the other hand, it's the most robust way to
ensure that fullscreen effects integrate correctly with the zoom effect.
For example, without it, the quick scene effect would need to figure out
what screen views to paint for the given screen. There are also more
finicky cases, e.g. the screen transform effect.
BUG: 447002
BUG: 447670
BUG: 453467
Tested-by: Merge Service <https://invent.kde.org/plasma/kwin/-/merge_requests/2451>
Part-of: <https://invent.kde.org/plasma/kwin/-/merge_requests/2451>
Under kwin_wayland `kwinApp()->connection()` is for communicating with
XWayland, but in X11Windowed backend we need to talk to the host XServer.
Restore `XRenderUtils::init` and set it accordingly based on
whether we're running standalone or windowed, so that `kwin_wayland`
works running nested in an X session again.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
Tested-by: Merge Service <https://invent.kde.org/plasma/kwin/-/merge_requests/2457>
Part-of: <https://invent.kde.org/plasma/kwin/-/merge_requests/2457>
With some effects, latency policy doesn't matter and it's preferred if
kwin uses the smoothest animation latency policy in order to minimize
the number of frame drops, e.g. slide.
After commit c1d0aa18, the namespace where the KCM is installed
changed to `plasma/kcms/systemsettings/`.
We need to point to this new plugin location when the KCM is
launched via Alt-F3 > "Window Specific Properties"
Also let's set the full plugin location from CMake instead of
harcoded in C++ so it is easier to keep it in sync.
BUG: 454066
FIXED-IN: 5.25.0
The Blendchanges effect works by showing a snapshot of the current
screen for a few ms. Any other active full screen effect will look
broken, so it should take priority.
This is pre-empting an issue with a new Plasma feature that syncs
colours to wallpapers. Once we animate activity switches / have per
desktop wallpapers it'll glitch out.
Firstly we weren't waiting for a signal at all, we are relying on events
being processed externally which is wrong.
Secondly ScreenLocker::KSldApp::self()->lockState() is tri-state;
unlocked, acquiring, locked. This gets compressed to a boolean where
acquiring and locked are the same.
If we run the tests whilst we're still acquiring the lock screen we can
call unlocked before we've finished locking. The greeter might then be
shown afterwards triggering a re-lock. It's a confused state.
The XRender backend has been removed, leaving most of KWinXRenderUtils unused.
The few features that are still used, notable `XRenderPicture` and pict format
are moved into the x11/common directory.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
For some reason with legacy the cursor gets an offset when changing the
image. In order to work around this, directly issue a cursor move with the
corrected position when changing the buffer
As we don't provide any ability for the user to configure the gestures yet,
the gesture for the desktop grid should stay as it was in the last release.
This commit swaps the gestures for desktopgrid and overview to achieve that.
At the moment, the data offer initializes supported and preferred action
to "none". But if the target doesn't accept anything the source
provides, the compositor may still need to send action events with "none"
This change makes data offer and data source provide dnd actions wrapped
in std::optional in order to indicate if they have been set explicitly.
SeatInterface emits dragEnded when the drag is dropped. The target may want
to interact with the data source after the drop happened, for example only
fetching data after the drop and not during the drag.
(Note that the Wayland protocol has the same
Xvisits are now not deleted prematurely but only when they are really finished.
(Note that the Wayland protocol has the same distinction between dropped and
finished so it maps nicely).
For storing previous visits the same code pattern as in the rest of the XWayland
DND code is used.
The SelectionSource is reset when the next Drag/Drop operation involving a X window
is started (see startDrag and doHandleXfixesNotify) or when the Wayland source is
about to be deleted.
BUG:450460
FIXED-in:5.25.0
Gesture recognition code doesn't handle correctly cancelling a touch
sequence. testTouchPoint in one of its tests simulates pressing the
screen with three fingers and cancelling the touch sequence.
Emitting the Workspace::windowAdded() signal before actually adding the
window to the Workspace is counter-intuitive and it can a source of
potential bugs as relevant window lists in Workspace don't contain the
window yet.
The features that this KCM lets you trigger barely work on X11 and
really only work properly on Wayland.
Unfortunately we don't have the ability to have separate settings
between X11 and Wayland, and for this reason we removed a default left
touch edge in 3df7985570 a year and a half
ago because it was too buggy on X11.
This commit takes the next step and hides the KCM entirely on X11, so
you can only use it on Wayland where it actually works properly.
One potential downside is be that any users who are actually using it
on X11 will lose the ability to use a GUI to configure these features
unless they go to the Wayland session to do it. However the number of
such users is likely small given how the feature does not really work on
X11.
However the upside is that Wayland users who can see the KCM can
actually use the features that it lets you configure because they work
properly there.
As it turns out, it's needed to ensure that the Workspace emits the
stackingOrder changed signal when a new window is added. It's also
implicitly needed to make sure that Window::stackingOrder() is updated.
