As is, kwin with the drm backend results in the most pleasant user
experience on Wayland. Given that and the fbdev being about to be
dropped, making libdrm a required dependency seems a reasonable decision.
Many reasons have been brought up over the years for why this effect is
not appropriate to be enabled by default:
- It was designed to highlight the whizzy technical feature of being
able to make windows transparent, which is no longer particularly
impressive today.
- It looks visually dated.
- It can produce a confusing visual soup by blending a window being
moved or resized with the content below it, which we recently disabled
for the Highlight Windows effect.
- If one window is covering up another as a way to deliberately hide the
content of the lower window, this effect will reveal the hidden
content whenever the upper window is moved or resized at all.
Overall it does not seem to have enough advantages to offset these
issues. Let's disable it by default--but only for the people who did not
modify its configuration at all. We can assume that those people like
it, so let's keep it on for them.
BUG: 384054
FIXED-IN: 5.23
Closes Phab task T7915
It's needed to make kwin_wayland properly systemd managed. A service
launched using systemctl --user is per user, not session.
As a consequence, user services run outside the session. Applications
that deal with user session need some quirks to work with systemd boot.
Unfortunately, GetSessionByPID() doesn't work well with systemd boot,
see bug 433364. GetSession(auto) is shown to work better.
With the client-side decoration changes, kwin will properly determine
whether the window needs to be configured even if the frame geometry has
not changed.
This change slightly changes the semantics of the setFrameGeometry()
method. Prior to this, it was possible to force a geometry, i.e. block
other geometry updates, however such a behavior is counter-intuitive and
it exponentially increases the complexity of code.
As far as I know, the force flag was needed to propagate geometry
changes if the frame geometry doesn't change, but the client geometry
does. With the client-side decoration changes, the force flag is not
needed, as kwin now takes into account the client geometry and the frame
geometry when determining whether to send a configure event.
If a minimized window is animated by the AnimationEffect, the final
layer repaint will be ineffective. In order to account for that, the
AnimationEffect adds the layer repaint to data.paint in the
prePaintScreen() hook. The issue with this hack is that it does not
work on Wayland with per screen rendering.
If a window is animated on screen B, but the layer repaint is added
to data.paint when screen A is painted, there will be a ghost of the
window on screen B.
In order to fix this issue, we need to use effects->addRepaint(), but
we cannot use it in prePaintScreen() as it won't have immediate effect.
effects->addRepaint() can be called either from window paint hooks
or from the postPaintScreen() hook. This change goes after the latter
option.
In the prePaintScreen() hook, AnimationEffect will only advance
animations. In the postPaintScreen() function, it will perform final
janitorial chore.
The internal EventQueue is a child of the registry object. This means
that after the registry is destroyed, all proxy objects in that event
queue are going to have invalid reference to it, which is not a problem
as long as the wl_display_dispatch() function is not called.
The wl_display_dispatch() function uses wl_proxy's queue reference to
enqueue incoming events to that queue.
Unfortunately, during teardown, the internal ConnectionThread may
dispatch events right after the registry object has been destroyed,
which can lead to a crash.
In order to fix the crash, we need to destroy all proxy objects and only
after that we can destroy the event queue. It's okay if wayland events
are dispatched in between.
This allows Task Switcher visualizations to know whether compositing is
active or not so they can adjust their visual representations
accordingly, if needed.
This reverts commit 110182b213.
The reverted commit has introduced a regression where interactively
moved windows jump back to their old position. This needs some time for
proper investigation. Due to beta rolling out quite soon, it will be
better to revert the change.
Rather than have an error prone way to detect whether a configure event
has good position information, handle the case where the plasma shell
surface has a position hint explicitly.
On X11, the lockscreen greeter is an override-redirect window so the
scale and the glide effect ignore it.
On Wayland, the lockscreen greeter is a regular window so both effects
try to animate it upon the screen being unlocked, which looks bad.
This reduces the number of usages of xStackingOrder(), which simplifies
the reasoning about when it can be marked as dirty.
Since internal windows are now in the regular stack, InternalWindowTest
can use stackingOrder().
As for X11ClientTest, there's no specific reason why it uses the x stack
instead of the regular one.
So far we were only tracking the first touch point, meaning that if 2
touch points were applied to the internal window and removed one, the
second's events would then be sent to Wayland, which would assert since
it didn't know it had been pressed in the first place.
This fixes InternalWindowTest::testTouch
We want panels to be behind fullscreen windows, but osd windows above
them. With the current layer promotion logic, the panel will be promoted
to the osd layer, which is undesirable. This change restores the old
behavior by allowing layer promotion only to ActiveLayer.
BUG: 436985
It's inherited by XdgToplevelConfigure and we need to make sure that the
object gets destroyed properly.
Alternatively we get a new-delete-type-mismatch error in ASAN and
rightfully so.
Workspace::constrainedStackingOrder() is a constant source of issues.
This change replaces the current logic that builds the stacking order to
hopefully make constrainedStackingOrder() less crashy.
With the new version, constrainedStackingOrder() doesn't perform layer
caching. On the other hand, it's quite rare to see apps in the wild that
have more than just 1 or 2 members in the window group.
BUG: 436095
