The normal stacking order contains managed and unmanaged windows now.
This kind of breaks dragging from X11 to Wayland clients.
When an X11 client is the drag source, it's going to create an override
redirect window for the drag icon, which is beneath the pointer.
findManagedToplevel() will return the drag icon instead of the window
beneath the drag icon.
The root problem is that normal event processing has different needs. It
doesn't care about window type except when the screen is locked, while
dnd does. Perhaps it also makes sense to check whether the window accepts
focus.
This change introduces a specialized helper to pick the drag target.
Unfortunately, it amounts to some code duplication. On the other hand,
not sure that other options (such as adding flags to findToplevel()) are
better.
Currently windows are scattered in a few separate lists. If you need to
go through the windows, you have to do it piece by piece. On the other
hand, with the overhaul of window types, we've started converging
towards one universal type: Window. Keeping windows in the separate
buckets goes against this design.
Workspace::stackingOrder() already contains all windows. This change
repurposes Workspace::allClientList() from a list of "normal" windows to
all windows, i.e. Workspace::windows(), to be consistent.
There's one API change though. Scripting API will expose other window
types too. This is an intentional change so scripted effects could
operate with all windows. It also matches the current behavior observed
in libkwineffects, which exposes all windows as well.
Instead of having every DrmProperty store pending values, store the data
for the next commit in a separate and temporary type. This simplifies the
code and makes it possible to do commits in a separate thread
Using DMABufs only will not allow clients to fallback to MemFD buffers
in case they fail to import DMABufs for whatever reason and completely
break screen sharing in such case.
Ultimately the best solution would be to implement
https://bugs.kde.org/show_bug.cgi?id=462722, but that hasn't been done
yet, so for now let's use the existing approach of adding the names of
effects into the keywords list for this KCM to surface those effects at
the system level so e.g. people can find them with KRunner.
BUG: 467279
FIXED-IN: 6.0
Even though zwp_text_input_v2_content_hint and
QtWaylandServer::zwp_text_input_v2::content_hint represent the same
values, they are not the same from the compiler perspective.
QVector::count()'s return type is qsizetype. On a 64 bit platform, it's
equivalent to qint64, so "%d" does not suffice.
There are two ways to fix it: use PRIdQSIZETYPE or switch to the stream
operator. Since the warning format is not complex, this takes the latter
approach.
The order in which windows are painted is computed dynamically every
frame. On the other hand, with the introduction of items, it's desired
to avoid doing that so repaints can be scheduled as needed. The
unification also opens the possibilities for more rendering related
refactors to make the code nicer and more reusable.
This makes the behavior of the virtual backend more consistent with
wayland, x11, and drm backends. However, the main advantage is that it's
more nicer to memfd fallback code path in screencasting plugin.
Currently Deleted are destroyed with a delay to avoid dangling pointers
within the middle of painting.
On the other hand, it's reasonable to require not to delete windows when
kwin starts painting the screen.
Over the years, we refactored how deleted windows. They are always
unreferenced after finishing the current frame. So it should be fine to
destroy Deleted immediately now.
The differences between windowed and host flavors of the X11 backend
have become too big, so let's split EglOnXBackend to avoid abstracting
something that makes little sense.
It helps to express the ownership of the pipe fd in ScreenShotSinkPipe2
better.
ScreenShotSinkPipe2 is not made to take a FileDescriptor too because
it's complicated by CaptureInteractive().
