The indirection contributes unnecessary complexity. The usage of
std::weak_ptr and std::shared_ptr complicates the things further, e.g.
---
Ideally, same should be done with TabBox and TabBoxHandler, but that can be done in another MR.
"label" is already used.
Warning: The name 'label' (QLabel) is already in use, defaulting to 'label1'.
Warning: The name 'label' (QLabel) is already in use, defaulting to 'label2'.
Deleted windows are no longer destroyed using deleteLater(). They will
be destroyed immediately as Workspace goes through the window list
because the effects will be unloaded by that time.
Tabbox supports two operation modes: switching between windows and
desktops. Switching between windows is more commonly used. Desktop
switching is not exposed in user settings and it requires some advanced
knowledge of kwin's internals to enable it.
On the other hand, over the past years, we've double downed on effects
like desktop grid and overview to provide graphical means to switch
between virtual desktops.
This change drops desktop switching because it's effectively unused to
simplify the tabbox code, which can be very handy for the future
refactorings of window switching.
The `kwin_rules_dialog` executable was used to launch the rules
KCM on a specific window when called from the window menu
because we couldn't depend on the `kde-cli-tools` repo
Since now `kcmshell6` lives on KCMUtils we can call it directly
The property `flat: true`was set since the QML redesign and remained
unnoticed because it didn't actually work.
Now that the qqc2-desktop style has been fixed and correctly draws
flat (non-bordered) comboboxes let's remove it for a nicer look
(just the same as the have had all this time)
Currently, X11Window and Unmanaged call finishCompositing(), which tries
to destroy the window item and other associated compositing data.
Usually, it has no any effect on the window item and the effect window
because they are moved to the Deleted. However, it has some effect on
the XDamage handle.
If the X11 window is unmapped, it will destroy the XDamage handle. If
the X11 window is destroyed, it will do nothing. Why does it behave like
that? Because that's how the XDamage spec is written.
This change removes the call to finishCompositing() and refactors how
the XDamage is handled so Window::finishCompositing() is more generic.
If the X11 window is destroyed, SurfaceItemX11::forgetDamage() will be
called and SurfaceItemX11::~SurfaceItemX11() won't attempt to destroy
the damage handle.
If the X11 window is unmapped, SurfaceItemX11::destroyDamage() will be
called and destroyDamage() in SurfaceItemX11::~SurfaceItemX11() will
noop.
If compositing has been restarted, destroyDamage() in
SurfaceItemX11::~SurfaceItemX11() will destroy the damage handle.
Destroying a zwp_text_input_v3 object should be viewed as disabling it.
isEnabled property is cached because it cannot be computed in
_destroy_resource() handler. By that time, the resource no longer will
be in resourceMap(), so TextInputV3InterfacePrivate::isEnabled() will
erroneously return false even though we expect true.
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.
