Currently, input method relies on the fact that QObject::destroyed and
Window::closed are equivalent. But it's going to change, so make the
input method use a signal that's semantically better.
When a window is closed, a Deleted object will be constructed and the
Window's properties will be copied over to it. The long term plan is to
stop doing that, i.e. keep the Window alive but just flip a few flags to
indicate that it's been closed.
In order to unify decoration management, this change ensures that it's
okay to have decorations live as long as the Deleted.
It's needed to work around the cleanup logic of decorations.
Currently, decorations have a valid QObject parent and they're managed
using std::shared_ptr. That's not a perfect combination, but changing it
is also going to be an involved task because the QObject parent is used
to look up the Window.
In long term, it won't matter since we want to get rid of Deleted.
For what it's worth, it restores the order in which Deleted and normal
windows used to be destroyed prior to
995d509e45.
If a client owns several windows (for example it can be the case with
plasmashell) and it crashes, it's possible to encounter the following
case:
- xdg_wm_base resources are destroyed
- xdg_toplevel is destroyed
- another xdg_toplevel is destroyed
When kwin processes the destruction of the first xdg_toplevel, it may
ping the second xdg_toplevel. But the xdg_wm_base is already free()d by
that time, so kwin can access already released memory.
In order to prevent that, make the associated XdgSurfaceInterface
objects inert. Since XdgToplevelInterface and XdgPopupInterface will
become useless after destroying XdgSurfaceInterface, make them inert too.
As the spec states, it's illegal to destroy a bound xdg_wm_base object
while there are still alive xdg surfaces created by it so destroying the
surface role objects should be fine.
This can be useful for the screenshot capture tool if it needs some
information about the captured window or screen, for example to generate
the file name.
Aurorae decorations and several effects are powered by QQuickWindows
that render into offscreen surfaces.
Iterating through all windows and then calling winId() will create a
platform window including for our Aurorae decorations.
Not only is this wasteful but it caused an issue with resizing windows.
QWindow code updates the internal state directly if there's no
underlying platform window, if there is it delegates responsiblity to
the backend. Our own QPA didn't update geometry whilst hidden.
The result of that is Aurorae decorations "randomly" stop resizing
correctly as the contentItem stops resizing to the window size.
BUG: 465790
This makes effect specific cmake code more encapsulated. It's also more
readable if the translation domain is specified explicitly rather than
having it implicitly set by add_definitions().
Window::isShown only checks that it's not hidden, in this case it's not
that it's hidden it's that it's neither shown or hidden. Take the
readyForPainting attribute into account.
Currently it makes an assumption that the name of a scripted effect
starts with "kwin4_effect_" prefix, which has its issues. For example,
it will stop working if we choose to use simpler naming scheme.
This change reworks how the generic scripting kcmodule is constructed.
Instead of guessing kpackage type, make relevant kcms pass it explicitly
via the arg list.
There's other code that includes headers starting from src/ directory,
so putting the corresponding include_directory() in src/effects/ is
inappropriate.
KPluginMetaData::KPluginMetaData(QString) assumes that the file
specified in the string corresponds to a binary plugin now, not a
metadata file.
This fixes scripted effect kcms not working.
Wayland has a limited size for strings in arguments. We should truncate
any strings that come from user-defined data before sending.
We keep the full title around within kwin as it keeps logic simpler.
Size length logic is lifted from QWaylandWindow's setTitle
BUG: 465775
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
