Currently, ExpoLayout delays layout updates by using a singleshot timer
(primarily due to the author of the effect not being aware of
QQuickItem::polish() and QQuickItem::updatePolish()).
This change makes ExpoLayout schedule layout updates using QtQuick's
native item polish machinery, which gets triggered before rendering and
thus we can batch more geometry updates.
In addition to that, this change simplifies the initialization code in
ScreenView by making the fact that ExpoLayout is arranged right before
rendering internal to the WindowHeap type.
It's confusing to have two signals (virtualScreenGeometryChanged() and
screenGeometryChanged()) that indicate the same thing.
This change ports parts of kwin from the screenGeometryChanged() signal
to the virtualScreenGeometryChanged() signal with the main motivation to
drop the former.
The virtualScreenGeometryChanged() signal was chosen as the replacement
for the consistency sake with EffectsHandler's virtualScreenGeometry and
virtualScreenSize properties.
The current duration is 300ms, which is inappropriate for two reasons:
1. It's too slow
2. It doesn't match one of the standard durations. The effect should
ideally use those durations directly, but if this is not possible
for technical reasons, it should use the effective value of one of
those durations. Units.longDuration is 200ms which is the most
appropriate one to use here.
Therefore, change the animation duration from 300ms to 200ms to match
the standard Units.longDuration duration.
BUG: 441308
FIXED-IN: 5.23
This makes it easier to spot if the effect is activated while there is
only one maximized window.
Note that anchors.margins cannot be used unfortunately as it won't take
effect until the ExpoLayout item is fully constructed. It may take a
couple of cycles for the geometry to settle down, which makes reasoning
about how the effect works difficult.
BUG: 312146
Once an animation starts due to property change, it cannot be easily
re-targeted. This can cause undesired animation jumps if a property
changes during startup (for example from 0 to its final value).
With this change, the window heap's animation will be disabled until
the effect starts the intro animation.
The ExpoLayout delays relayouting for optimization purposes. However,
this means that new geometry will be available only after returning to
the event loop.
This change delays starting the intro animation so it can be started
with new geometries.
According to the Qt documentation, if an item overrides the
geometryChanged() method, it must call the base class method.
QQuickItem::geometryChanged() is responsible for emitting signals such
as xChanged(), yChanged(), etc.
Currently, window thumbnails may be placed behind the panel, which
doesn't look good.
With this, the window heap will cover the same area as the maximize
area.
This makes the WindowHeap more robust to layout changes. Currently, the
main issue with it is that thumbnails will be misplaced if the heap's
scene position changes.
Kirigami.ScenePosition automagically keeps track of the item's scene pos.
This effect is meant to be as a replacement for the present windows and
the desktop grid effect. It is written using QML.
So far, this effect implements only the basic features of the present
windows effect. Desktop management features will be added later.
CCBUG: 295775
CCBUG: 303438
This reverts commit ac16bef409.
It causes crashes and color channels seem to be swapped.
GLTexture::toImage() needs more work before it can be used in the
screenshot effect, or maybe dropped.
Makes it possible to apply the dpms settings per screen instead of
applying it to all of them, which is wrong at many levels.
Will be even more important with other effects like rotation.
This allows creating a GLTexture object and attaching a dmabuf to it.
Currently, we can do that by using the foreign GLTexture constructor,
but it makes the deletion of the texture handle more error prone.
In the future, we can add a method that allocates the texture storage,
but there's no need for that yet.
The pointing finger cursor is used to show that a piece of text is a
clickable link, and it is inappropriate to use it in other contexts.
Regular UI elements that do something when single-clicked continue to
use the standard arrow cursor in other contexts, so let's follow that
convention in the Present Windows and Desktop Grid effects too.
BUG: 421928
FIXED-IN: 5.23
The Xrender backend was added at the time when OpenGL drivers were not
particularly stable. Nowadays though, it's a totally different situation.
The OpenGL render backend has been the default one for many years. It's
quite stable, and it allows implementing many advanced features that
other render backends don't.
Many features are not tested with it during the development cycle; the
only time when it is noticed is when changes in other parts of kwin break
the build in the xrender backend. Effectively, the xrender backend is
unmaintained nowadays.
Given that the xrender backend is effectively unmaintained and our focus
being shifted towards wayland, this change drops the xrender backend in
favor of the opengl backend.
Besides being de-facto unmaintained, another issue is that QtQuick does
not support and most likely will never support the Xrender API. This
poses a problem as we want thumbnail items to be natively integrated in
the qtquick scene graph.
With the ongoing scene redesign, it needs to be rewritten. However,
given that it is not used widely based on support information from
various bug reports and our available man power is sparse, the most
reasonable thing is to drop the effect, unfortunately.
With the ongoing scene redesign, it needs to be rewritten. However,
given that it is not used widely based on support information from
various bug reports and our available man power is sparse, the most
reasonable thing is to drop the effect, unfortunately.
With the ongoing scene redesign, it needs to be rewritten. However,
given that it is not used widely based on support information from
various bug reports and our available man power is sparse, the most
reasonable thing is to drop the effect, unfortunately.
With the ongoing scene redesign, it needs to be rewritten. However,
given that it is not used widely based on support information from
various bug reports and our available man power is sparse, the most
reasonable thing is to drop the effect, unfortunately.
EffectWindow::shape() doesn't fit the item based design. This change
ports the blur effect away from the shape() function to the rect()
function. The XShape extension was introduced when windows with an alpha
channel wasn't really a thing. Setting a shape served as a way to clip a
window, the most notable example is xeyes.
If an application relies on the xshape extension to actually clip the
window and not to force the window manager not to put the server-side
deco, it most likely doesn't support translucency and therefore it
shouldn't set the blur region to begin with.
This change makes the blur effect ignore the xshape region similar to
the background contrast effect. It allows us to decouple a bit more
effects from the rest of rendering machinery and thus make it easier for
us to move forward with the scene redesign goal.
Similar to the slide effect, the desktop grid can use the clip region to
clip windows when needed. This will improve performance because the desktop
grid effect will do less work. Currently, it clips quads on its own in
prePaintWindow, copies them over in a temporary list, and lets the opengl
scene clip the window quads again.
We can clip windows differently by just passing a custom region to the
paintWindow() function down the effects chain, which the desktop grid
effect already does.
The old behavior and the old bugs are preserved. The Xrender code path is
unaffected.
In general, on Wayland, there is no such a thing as "window scale factor"
because sub-surfaces can have different buffer scales. However, we know
the scale factor of the output where the window is considered to be on. So
we can use the screen's scale factor as the window's scale factor. In
most cases, it will produce the correct result.
For the scene redesign, window quads need to be removed from the effects
api. This change ports the screenshot effect away from quads.
In order to exclude the server-side decoration from the window
screenshot, the effect will render the contents of the client geometry
into the offscreen texture. If the window is client-side decorated, the
entire window will be rendered as before.
The good thing about this approach is that the screenshot effect will do
less work, it won't loop over window quads to compute the bounding rect
or filter out the deco quads.
Many reasons have been brought up over the years for why this effect is
not appropriate to be enabled by default:
- It was designed to highlight the whizzy technical feature of being
able to make windows transparent, which is no longer particularly
impressive today.
- It looks visually dated.
- It can produce a confusing visual soup by blending a window being
moved or resized with the content below it, which we recently disabled
for the Highlight Windows effect.
- If one window is covering up another as a way to deliberately hide the
content of the lower window, this effect will reveal the hidden
content whenever the upper window is moved or resized at all.
Overall it does not seem to have enough advantages to offset these
issues. Let's disable it by default--but only for the people who did not
modify its configuration at all. We can assume that those people like
it, so let's keep it on for them.
BUG: 384054
FIXED-IN: 5.23
Closes Phab task T7915
On X11, the lockscreen greeter is an override-redirect window so the
scale and the glide effect ignore it.
On Wayland, the lockscreen greeter is a regular window so both effects
try to animate it upon the screen being unlocked, which looks bad.
According to the HIG, the InCubic easing curve should be used if the
animated item changes its state from visible to invisible and the
OutCubic easing curve if vice versa.
Since the scripted effects were ported to QJSEngine, it's possible now to
use ECMAScript 2015 perks such as classes, let and const.
This change ports the scale effect to some ES6 features to make the code
neater.
Reducing the oppacity of these windows causes them to appear as phantoms
in the corners of the screen. They look quite odd on top of anything else
in the corners of the screen, such as any Plasma panels.
However making them 100% opaque doesn;t work either, since then they
look interactive, but they're not, and can't be made so due to the
scripting API used here.
So our only real option to remove the weirdness is to make them 100%
transparent, and therefore show the entirety of the desktop with no sign
that the effect is in use.
The last presentation timestamps should be reset when all animations
finish rather than when the effect finishes. Otherwise, the calculated
time diff for the first animation frame will be too big.
BUG: 433471
Showing the panels makes this effect a little bit more integrated
with the desktop. With the panels disabled it creates a separate state,
with the panels enabled it creates a more friendly state with
the effect adding to the already existing experience.
With the new interface, the compositor sends raw image data instead of
encoding it as a png image, which causes a lot of overhead on Wayland.
In addition to that, the new interface is more extensible, for example
we can add new options or change the written image data format, however
the latter is less likely to happen.
BUG: 433776
On Wayland, when the compositor sends a screenshot to the requesting
app, it encodes the screenshot as a PNG image and sends the encoded data
over the pipe. The requesting app (Spectacle) then needs to decode the
data.
The issue is that encoding PNG images is not cheap. This is the main
reason why Spectacle is shown with a huge delay after you press the
PrtScr key.
In order to fix the latency issue, we need to transfer raw image data.
Unfortunately, the current dbus api of the screenshot is too cluttered
and the best option at the moment is to start with a clean slate.
This change prepares the screenshot effect for versioned dbus interface.
Most of existing dbus logic was moved out in a separate class. In order
to schedule screen shots, the screenshot effect got some new API.
QFuture<QImage> scheduleScreenShot(window, flags)
QFuture<QImage> scheduleScreenShot(area, flags)
QFuture<QImage> scheduleScreenShot(screen, flags)
If a dbus interface needs to take a screenshot, it needs to call one of
the overloaded scheduleScreenShot() functions. Every overload returns a
QFuture object that can be used for querying the result.
This change also introduces "sink" and "source" objects in the dbus api
implementation to simplify handling of QFuture objects.
Note that the QFutureInterface is undocumented, so if you use it, you do
it on your own risk. However, since Qt 5.15 is frozen for non-commercial
use and some other Plasma projects already use QFutureInterface, this
is not a big concern. For what it's worth, in Qt 6, there's the QPromise
class, which is equivalent to the QFutureInterface class.
CCBUG: 433776
CCBUG: 430869
This provides the compositor a way to indicate what output is being
rendered. The effects such as the screenshot can check the provided
screen object in order to function as expected.
In QJSEngine, QRect is an Object, which is correct. This means that we
cannot use simple assignment operator to copy geometries, we need to use
standard ways to copy Objects, such as Object.assign() or the spread
operator, which is not available in QJSEngine yet.
Currently, the wobbly windows effect assumes that the window data will
be updated on every repaint. However, there are legit cases when the
time diff between frames can be 0, for example when per screen rendering
is on.
If we are unlucky enough and the geometry of the window changes in that
very short moment, the mapping between window quads and the bezier
patch will be wrong. The window will most likely bounce back and forth.
In order to improve handling of that tricky case, this change makes the
computeBezierPoint() function take the "uv" coordinates rather than the
absolute "xy" coordinates of window vertices. This loosens the
connection between the real geometry of the window and the cached bezier
patch, and overall makes the effect's timing code more robust.
This can be also useful if the wobbly windows effect starts accumulating
time diffs and performing the integration step every N msecs with the
purpose of maintaining uniform "wobbliness" across different refresh rates.
BUG: 433187
Once in a while, we receive complaints from other fellow KDE developers
about the file organization of kwin. This change addresses some of those
complaints by moving all of source code in a separate directory, src/,
thus making the project structure more traditional. Things such as tests
are kept in their own toplevel directories.
This change may wreak havoc on merge requests that add new files to kwin,
but if a patch modifies an already existing file, git should be smart
enough to figure out that the file has been relocated.
We may potentially split the src/ directory further to make navigating
the source code easier, but hopefully this is good enough already.
