Prefering alpha is needed for some interactions with video underlays; more
directly choosing formats with an alpha channel will be needed for overlay
planes, too.
The Window View effect is a companion effect for the task manager. It
provides the task manager a way to ask the user to pick a window among
windows identified by window ids passed to the activate() method.
The main motivation for adding this effect is to provide a QtQuick based
alternative for the present windows effect, which is needed to kill the
latter.
This change doesn't extend the overview effect to avoid repeating
mistakes of the past, i.e. adding too many (unrelated) features to the
present windows effect.
While the overview effect provides you a way to select windows, it's not
the only thing that it has. For example, it also allows changing virtual
desktops, etc.
On the other hand, the task manager doesn't need all of that. It only
needs to ask the user to pick a window among the specified windows, nothing
more.
As is, the window view effect is simply WindowHeap with a d-bus api slapped
on top of it.
The main motivation behind this change is to unify render target
representation across opengl and software renderers and avoid accessing
the render backend directory in order to get the render target.
GLRenderTarget doesn't provide a generic abstraction for framebuffer
objects, so let's call GLRenderTarget what it is - a framebuffer.
Renaming the GLRenderTarget class allows us to use the term "render
target" which abstracts fbos or shm images without creating confusion.
With these two actions being separate, RenderLoop can record the time spent
in endFrame (for example for multi-gpu transfers) without risking also recording
blocking swapbuffer calls, and endFrame can later be moved to output layer
In the desktop grid effect, dragging an empty area of a desktop to
another desktop swaps all windows on the two desktops. This change makes
sure that this matches only windows in the current activity.
BUG: 386769
FIXED-IN: 5.24.5
When setting-up the plasma window interface we need to call
`setOnAllDesktops()` after the actual virtual desktops have
been set.
Otherwise, the current desktop would be always added to the
interface (as if the user were unsetting the "onAllDesktops"
flag) and the plasma interface and KWin can get un-synced,
specially if there are specific window rules.
BUG: 452171
FIXED-IN: 5.24.5
On x11 when multiscreen is enabled often kwin crashes on
laptop lid close, for two reasons:
* m_outputLayer going dangling in RenderLayer: fixed by using a QPointer
* m_activeOutput going dangling in Workspace
For the latter, the output disabling was done correctly, but x11client did set the old deleted output
again in X11Client::moveResizeInternal
This is fixed by moving desktopResized() at the bottom of
Workspace::slotOutputDisabled() after the reassign of outputs to
the toplevels
Reduce the code duplication and boilerplate to create and destroy
the test clients by making the related variables class members.
Handle special cases using an extensible flag mechanism.
In 5.24, the same code path is used for testing direct scanout, so that
causes false negatives. Generally though, the user setting shouldn't be
touched, it's not really proper feedback for the driver or KWin having
problems.
Some modes can have the exact frame timings but different flags.
Currently, the mode comparison function doesn't take that into account
which can result in the drm backend setting the current mode flag
incorrectly.
If no mode has the current flag set, the first mode object will be
announced twice.
There's also no benefit from sending the current mode as last. If the
current mode changes, the compositor will send the current_mode event,
not the mode event.
BUG: 452318
Since the Toplevel.output property is properly synchronized with the
frame geometry, Workspace::clientArea() can use the output property
instead of looking up the screen. It makes code intuitive and removes
unnecessary lookups.
Currently, if geometry updates are blocked, the Toplevel.output property
won't be updated. On the other hand, it's reasonable to use the output
property instead of manually looking up the output in window management
code, e.g. Workspace::clientArea().
In other words, using the Toplevel.output property is like walking on a
mine field, things can blow up. You can't use Toplevel.output even if it
makes perfect sense.
This change ensures that Toplevel.output property is always kept in sync
with the frame geometry. Unfortunately, this means that the output
property no longer can be updated when the frameGeometryChanged() signal
is emitted. It has to be done in moveResizeInternal() method.
