Right now it's just a helper to mark items as being affected by some effect,
to prevent direct scanout of the relevant item without needing to block direct
scanout for the whole screen
The effect only modifies the opacity of individual windows that
WorkspaceScene::scanoutCandidate will reject anyways, so there's no reason
for it to block direct scanout.
Once a more proper solution for blocking direct scanout on individual items
is in place, this can be removed again
BUG: 487780
Makes it so the GlobalShortucts object gets built and its KGlobalAccelD
parts get disabled.
Addresses the TODO in GestureHandler.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
If a SwipeGesture or a PinchGesture is cancelled, the associated QAction
is going to be triggered. It is against the expectations of the gesture
handlers.
In order to address that, this ports the gesture handlers to the native
gesture apis, which expose whether the gesture has been started or cancelled
better.
When filtering windows by screen, match the screen closest to the window
center, instead of testing whether the window is visible on the current
screen. The new method guarantees that when filtering by screen, the
window appears for exactly one screen. Previously windows spanning
multiple screens appear on all of them, and off-screen windows are not
shown in any screen.
BUG: 480028
BUG: 485337
FIXED-IN: 6.0.4
Adds whitespace between documented members of the header file.
Currently the members are all bunched together, making it difficult to
read as one flows directly into the next. This change adds a newline
between each member, making it easier to read.
Now that we have Wayland around, there's a whole branch of dependencies
that shouldn't be necessary anymore.
This allows to build KWin without all of it, allowing us to have a much
more compact alignment for cases where all the legacy software isn't
necessary anymore.
Bundle KWindowSystem X11-specific headers into it too, since it's part
of the same process.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
Drops the doneCurrent as it was preventing proper cleanUp
because no context was current when textures were deleted.
Also avoid manipulating the context when Qt has the current
one, as various Qt classes have guards around their cleanup
handlers which rely on a current Qt context.
Despite the comment the order of render control and view destruction
needs to be switched as the QQuickWindow destructor calls into
the render control to notify if of window destruction.
BUG:478770
BUG:479846
FIXED-IN:6.0
Effects like overview can create more than one thumbnail for the same
window. For example, if you have 4 virtual desktops, the overview is
going to create 9 window thumbnails for the desktop background, which in
its turn means that each thumbnail is going to have its own texture.
That's not great.
WindowThumbnailItem.sourceSize has been dropped because it's unused and
will complicate texture caching.
CCBUG: 455780
libkwineffects was introduced when kwin used to be an executable. It
provided an api to implement effects and shielded from the technical
quirks in kwin.
Over the time, kwin internals had been split and abstractions were
refactored so they can be consumed in scripts or plugins. Besides that,
new ways to implement extensions have been introduced, which use
kwin's internal abstractions.
On the other hand, effects continue using libkwineffects specific apis.
This has a few issues: qtquick effects use both apis and it bites us,
duplicating same apis.
The best solution so far is to merge libkwineffects with libkwin, and
replace libkwineffects abstractions with libkwin abstractions, e.g.
EffectScreen -> Output, etc. This change takes care of adjusting libs.
Obviously, the main disadvantage of doing so is that binary effects
have to be recompiled every time new libkwin is released. But it's
already the case with libkwineffects too.
with itemChange watching SceneChange is more efficient than connecting
to the windowChanged signal, also this won't arrive during teardown,
aoiding the "destructor already ran" assert.
* speeds up incremental builds as changes to a header will not always
need the full mocs_compilation.cpp for all the target's headers rebuild,
while having a moc file sourced into a source file only adds minor
extra costs, due to small own code and the used headers usually
already covered by the source file, being for the same class/struct
* seems to not slow down clean builds, due to empty mocs_compilation.cpp
resulting in those quickly processed, while the minor extra cost of the
sourced moc files does not outweigh that in summary.
Measured times actually improved by some percent points.
(ideally CMake would just skip empty mocs_compilation.cpp & its object
file one day)
* enables compiler to see all methods of a class in same compilation unit
to do some sanity checks
* potentially more inlining in general, due to more in the compilation unit
* allows to keep using more forward declarations in the header, as with the
moc code being sourced into the cpp file there definitions can be ensured
and often are already for the needs of the normal class methods
