When we delete a window we unredirect, when we unredirect, we delete the
framebuffer which requires an openGL context.
handleWindowDeleted is the entry point from workspace events to effects
code, so it's made current here.
BUG: 444665
BUG: 471139
We were binding to the statusChanged signal, but then only doing
anything if the status had changed to "Activating". This did not work
for when the effect was activated without a gesture, because then its
status would change straight to "Activated", bypassing the in-between
state of "Activating."
This fixes clearing the search text on activation without a gesture.
This change makes the EffectsHandler emit the windowAdded signal as soon
as the Workspace::windowAdded signal is received and minimize the
difference between the states observed in kwin core and effects.
This will ensure that the window animation is advanced only if the
window is painted. I'd like to rely on this to allow effects schedule
animations as soon as Workspace::windowAdded signal is emitted.
As is, the issue with delaying EffectsHandler::windowAdded is that we
don't filter out all "not ready" windows, which breaks some effects
because EffectWindows are leaked in some properties but no
EffectsHandler::windowRemoved signal is emitted so those effects can
perform cleanup. Fixing that by the means of ensuring that only renderable
EffectWindows are exposed is hard too, and it would also mean that
effects need to use their own api, which I would like to avoid and port
the effects to kwin core apis instead.
Don't fall back into other composition systems if KWIN_COMPOSE is
explicitly set. In such case, just exit().
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
Alpha from clients is encoded in electrical values, and some of our code also relies
on compositing results being encoded in electrical values. To take care of this, we
need to undo the premultiplication of rgb values, convert to or from linear, and then
re-do the premultiplication. This doesn't result in exactly the same blending behavior
with linear blending, but it's close enough
Now that decoration configs are separate plugins we can plug those into KCMultiDialog instead of hand-rolling it ourselves
As a nice side-effect this should allow to implement the decoration config in QML
BUG: 470902
The test is flaky. We work around it by passing --repeat until-pass, but
lately even it doesn't help us with this issue.
So skip the test when running it inside KDE CI for a few months until
it gets a newer kernel.
It makes decorations lighter as they don't need to bundle its
configuration logic.
Deprecates the kcmodule property in favour of kcmoduleName which instead
of assuming that the kcm is local to the plugin, it provides the plugin
name to find and load.
It appears PyCharm can change WM_HINTS propery of override-redirect
windows when they are closed, which triggers a crash in kwin.
This change adds the corresponding guard. In addition to the icons, it
adds a few more guards to prevent kwin crashing when a rogue client sets
wrong properties on an override redirect window.
BUG: 470874
Floating point arithmetic and/or the use of GL_LINEAR in the pipeline,
may result in visual glitches due to rounding (errors). As a short-term
fix until a proper (more involved) solution is in place for Plasma 6,
pad the damage slightly in all directions to alleviate those effects.
The main motivation for the rewrite is to properly port ShmClientBuffer
to our GraphicsBuffer abstractions. As is, libwayland implementation is
not suitable for our needs. We may need ShmClientBuffer to be alive when
its corresponding wl_shm_buffer resource is destroyed, for example to
play a window closing animation. With the existing api, we need to fight
libwayland. Besides that, libwayland doesn't provide a way to get
underlying pool file descriptor, which is needed to fill ShmAttributes.
kcmutils_add_qml_kcm creates a QRC that contains the "ui" folder.
This this simplifies the installation of KCMs, because all needed files
are bundled with the plugin.
In KCMUtils this means we can get rid of KPackage.
The new org.kde.kcmutils QML module also contains the org.kde.kcm
components that were previously part of KDeclarative.
Depends on https://invent.kde.org/frameworks/kcmutils/-/merge_requests/146
If a closed window is kept alive, it means that somebody needs to
animate it and therefore it should be visible. Otherwise the window
would be destroyed and its item would be removed from the scene.
This change makes the WindowItem not change its visibility if the
associated window is closed. If the window had been invisible before
it was closed, the item would be invisible; if the window had been
visible before it was closed, the item would be visible.
Currently, when a window is added or removed, the work area will be
recomputed unconditionally. But in many cases, it's unnecessary because
only a small fraction of windows has a strut (in default setup, only the
panel has a strut).
