When no qml items manage the arrow key event, the root item will manage it looking to give focus to a view in the given direction derived from the arrow key
BUG:455783
Right now we update QtQuick views after a composition has rendered so
that we'll have them ready for our next frame.
One of my machines (With X11 + nvidia) was quite stuttery, profiling
shows we spend a huge amount of time with the CPU blocked waiting for
the vblank from the previous main compositing to finish swapping before
we could start processing the QtQuick rendering. Time when the CPU is
blocked is wasted time.
This patch does mean kwin's compositing cycle lasts longer but a recent
patch changes the rendering policy when we start a fullscreen effect anyway so
hopefully that should still give us enough time to render that first frame in time.
Since the screen number is well-known, we can look up the default
screen on demand. Note that xcb_get_setup() is pretty cheap as it
simply returns a const pointer to pre-allocated data.
Use SurfaceInterface::inputSurfaceAt when deciding which surface are we
entering when sending a pointer event from a touch, in case it falls
onto a subsurface.
BUG: 452967
This allows us to unify the X and Wayland codepaths that currently go
through window-system specific IPC. It also allows us to easily track
who called "setShowingDesktop" and cancel the effect when that client
disappears.
CCBUG: 449445
This is most likely just an oversight/omission from the times when the
component was actively developed. There are five states total, including
one for realtime interactions; four others need to be transitioned to.
Due to nondeterministic nature of signal propagation in QML, changing
both targetScale and state depending on dragHandler's activity could
result in targetScale wrongly updating before the state change(and thus
applied property changes and subsequent animated transition).
This fixes a bug when a window dragged to the top (but not onto another
desktop) would animate its position back to its original position on a
heap, but the scale would remain constant until the end of animation
and only then rapidly jump back to a normally scaled state.
Quad generation needs a valid surface pixmap. This did not surface
before as the pixmap was only accessed when looping the region which
typically was empty without a pixmap.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
This uses the previous pixmap if the current one is invalid,
which ensures the generated quads have sane coordinates.
The issue caused flickering while resizing Chrome after
2f4fa23e61
While at it, move `size` out of the loop as it doesn't change.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
If both compositor and applications were to use these gestures at the same
time, that would be quite confusing for the user. This also works around
a bug in Wine that makes applications crash.
BUG: 455952
This breaks cyclic dependency between Compositor and DRM backend, there
are still indirect dependencies though. However, fewer cyclic
dependencies should make the architecture more cleaner and easier to
tweak.
Otherwise this WindowHeap type is not usable without custom delegate.
/usr/lib/qml/org/kde/kwin/private/effects/WindowHeap.qml:111:23:
QML Component: Cannot create delegate
/usr/lib/qml/org/kde/kwin/private/effects/WindowHeapDelegate.qml:21:5:
Required property windowHeap was not initialized
Switches to a shared pointer rather than a raw one. It would leak, which
in general is not a big problem but it would flood the output when
running tests with ASAN. Also it's the right thing to do.
The wayland backend changes the dpms mode when the enabled state of the
output changes. This creates problems when destroying all outputs on
shut down. The wayland backend calls InputRedirection's methods, but
InputRedirection is already destroyed by that time.
While the crash can be fixed by guarding input() in createDpmsFilter()
with an if statement, changing dpms mode in updateEnablement() doesn't
seem like a good idea because Output changes unrelated states (enabled !=
dpms mode), so let's get rid of it.
This targetOpacity is nowhere to be found. This is a relic of past
development. Currently code that needs to alter opacity based on drag
state does so externally by setting opacity on a delegate as a whole.
On wayland the code to keep windows on the current activity whilst the
window was broken was completely broken in porting. We only held the
block for the duration of the method even though the popup remained open
for longer.
On X11, when removing the window from the current activity it would not
update correctly and remain visible. The code path was as follows:
- the menu is shown an event loop is started
- we change the activities
- as we close the menu focus changes and workspace calls
UserActionsMenu::close this unsets m_window
- We then never call the blockActivityUpdates(false) at the end of
UserActionsMenu::show
This patch addresses both at once.
We get rid of the nested event loop as that was always evil. This means
slotWindowOperation no longer needs to be queued.
We perform cleanup of m_window and the activity blocker when the menu
closes which should be safer.
BUG: 456873
At the moment, a platform should provide two output lists - one that
lists all available outputs, and the other one that contains only
enabled outputs. In general, this amounts to some boilerplate code and
forces backends to be implemented in some certain way, which sometimes
is inconvenient, e.g. if an output is disabled or enabled, it will be
simpler if we only change Output::isEnabled(), otherwise we need to
start accounting for corner cases such as the order in which
Output::isEnabled() and Platform::enabledOutputs() are changed, etc.
