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
Currently, the Workspace has no any api to constrain one window above
another. This results in having hacks such as keepDeletedTransientAbove()
This change introduces a basic api to constrain a given window above
another. It can be used for ensuring that transient windows are placed
above their parents. It also can be used for stacking the outline window
below the move-resize window.
Internal windows may also have transient parents. Because of that, this
change makes the workspace add internal clients to the stacking order by
default. The good thing about it is that it allows us unify some input
related code for "external" windows and internal windows.
We need to make sure that the information from
toplevelConfigureRequestedSpy is in place to be used, otherwise we get
an empty size and it doesn't work.
According to the HIG, the InCubic easing curve should be used if the
animated item changes its state from visible to invisible and the
OutCubic easing curve if vice versa.
Aleix Pol