Item type is incredibly fragile as a way to determine what was dropped,
as proven by recent breakage. Instead, we can use `Drag.keys` to provide
metadata about what is being dragged/dropped.
The overview effect uses the type of the dragged object to determine
if a single window is dragged or the entires desktop.
Commit 0ff4f84a changed the type of mainBackground, but did not
update the code for matching the type.
BUG: 478746
FIXED-IN: 6.0
In default shortcuts, change +Shift+Backtab to +Shift+Tab.
Functionally the behavior doesn't change.
But Shift+Tab is better since it is
- easier to understand (not everyone knows what Backtab is)
- more consistent with other shortcuts containing Shift:
we use Alt+Shift+1, instead of Alt+Shift+!
- more consistent with how user defined shortcuts with Shift and Tab are
displayed and stored
BUG: 422713
FIXED-IN: 6.0
This causes a longer compile time, because lots of unneeded files are
included. With https://invent.kde.org/sdk/clazy/-/merge_requests/91/
lots of false positives in the clazy check were resolved, this commit
takes care of the remaining places
Some OutputTransform code assumes that Kind enums have specific values.
In order to ensure that that code doesn't break if the enums are reordered
or something, this change sets output transform enums to those explicit
values.
The naive way to combine output transforms is not great, especially
because of the for loop.
The output transform kind enums have the following bit pattern:
- rotate-0: 000
- rotate-90: 001
- rotate-180: 010
- rotate-270: 011
- flip-0: 100
- flip-90: 101
- flip-180: 110
- flip-270: 111
`(rotate-a + rotate-b) & 0x3` can be used to combine two rotation
transforms. The rotatation is clockwise.
If the first transform is a flip transform, then we should rotate
counter-clockwise, i.e. `(rotate-a - rotate-b) & 0x3`.
When users simultaneously press Shift and Tab, the keys are sometimes
registered as Shift+Tab, and sometimes as Shift+Backtab.
So we need to match received Shift+Tab against shortcuts containing
Shift+Backtab, and vice versa. Previously the code only checks for
the first case. This commit adds checks for the second case.
BUG: 438991
FIXED-IN: 6.0
Our painting code is assumed to work as following: scale the geometry,
snap it to the pixel grid, apply the render transform, e.g. flip the
geometry vertically.
However, with QMatrix4x4 in RenderViewport, we have a slightly different
order: scale the geometry, apply the render transform, snap to the pixel
grid. It results in mapToRenderTarget() not properly mapping logical
geometry to the device geometry, which later manifests as glitches.
BUG: 477455
Automatic backend selection is a very normal by-design activity that warrants informing. Decrease from log level Warning to Info to avoid spoiling the log at too high of a log priority.
If an output is disabled, the Output object will be kept alive. That
means that the aboutToChange connection will be kept.
If the output is enabled again and its transform changes, its contents
will be captured more than once.
In order to fix, the screentransform plugin has to break the
aboutToChange connection.
If the output configuration doesn't touch the output transform,
capturing the previous screen contents is pointless.
I believe the main reason why the screen transform operates this way is
because it couldn't access OutputConfiguration before.
Polling the dmabuf for readability doesn't appear to work on NVidia and
we're no longer using an egl surface where the driver does this for us,
so we need to explicitly wait for rendering to complete or there are glitches
on the output
The OpacityMask is used purely for rounding the corners. We can get rid
of it by using ShadowedTexture which does the same thing while also
drawing the shadow, meaning we can also eliminate the ShadowedRectangle.
If the wl_surface is unmapped, the compositor should unmap the window.
Most clients don't do it, and instead destroy the wl_surface or the
surface role object or both. A very tiny fraction of clients actually
close the window by unmapping the wl_surface. Either way, it's worth
handling that case because xdg-shell protocol says that the clients are
allowed to do it.
BUG: 478297
OverlayWindow had different paths for GLX and EGL when it came to
managing size. On EGL the initial size comes from the overlay resizing
to workspace, but future updates were explicitly handled by the backend.
On GLX the backend tracked changes, but then it was the overlay's job to
resize but using a different method.
This patch also prevents use of workspace after destruction fixing
kwin_x11 --replace.
Milou.ResultsView loads runners regardless whether the query string is
empty. It's not clear what milou should do. There are valid arguments
both in favor and against preloading runners.
This change puts Milou.ResultsView behind a Loader so milou is loaded
when it's actually needed and not when starting overview.
CCBUG: 455780
Captions are set to elide with ElideRight, which does allow for multi-line captions.
However, this means that the height of the captions depends on their width (since a shorter
width results in more lines), and the width of the captions depends on the size of the
window thumbnail, which depends on the height of the caption to be positioned. If the
caption is really long, this can cause visual glitches. Having a maximum line value avoids that.
BUG: 477103
