Summary:
So far the window decoration was not considered and e.g. right clicking
the window decoration resulted in two open popups - one by KWin and one
by the application. This change addresses the problem by ensuring the
popup gets cancelled if the decoration is clicked. It's considered not
being part of the window.
Test Plan: Added test case which fails without the change
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5388
Summary:
So far KWin did not properly handle popup windows. That is when a popup
surface got created and a click outside the surface happened KWin did not
send out the popupDone Wayland event.
This change makes KWin aware of whether a surface is a popup and tracks
through a new PopupInputFilter whether there are popup windows. In case
there are popups the new filter waits for mouse press events and cancels
the popups if the press does not happen on any surface belonging to the
same client. To quote the relevant section of the Wayland documentation:
The popup grab continues until the window is destroyed or a mouse
button is pressed in any other client's window. A click in any of the
client's surfaces is reported as normal, however, clicks in other
clients' surfaces will be discarded and trigger the callback.
So far the support is still incomplete. Not yet implemented are:
* support xdg_shell popup windows
* verifying whether the popup is allowed to be a popup
* cancel the popup on more global interactions like screen lock or
kwin effect
BUG: 366609
FIXED-IN: 5.10
Test Plan: Auto test and manual testing with QtWayland client
Reviewers: #plasma, #kwin
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5177
Summary:
Consider the following situation: we have three InputEventFilter linked
in the sequence A - B - C.
The input filters are processing pointer motion events. The expected
behavior is that the new motion is processed in the sequence
A -> B -> C
So far this did not work correctly if the pointer gets warped during the
processing. If e.g. filter B warps the pointer we get a motion sequence:
A (1) -> B (1) -> A (2) -> B (2) -> C (2) -> C (1)
The filters following the one warping the pointer get first the newer
than the older position. This is obviously wrong. Unfortunately it is not
just a theoretical condition, but a condition happening when interacting
with the screenedges, which warp the pointer.
This change introduces a PositionUpdateBlocker in
PointerInputRedirection::processMotion to ensure that a processMotion
call finishes prior to the next update. If the PositionUpdateBlocker is
blocked the new position gets scheduled and processed once the
PositionUpdateBlocker gets destroyed.
With this we get the expected sequence for B warping pointer:
A (1) -> B (1) -> C (1) -> A (2) -> B (2) -> C (2)
This should hopefully improve the interaction with screen edges on
Wayland.
CCBUG: 374867
Test Plan:
Added an auto test demonstrating the issue of incorrect
ordering caused by screenedges. Prior to the change the test is failing.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5182
Summary:
This is a preparation step for no longer creating a socket in the tests
and slightly simplifies the init test code.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3575
So far KWin's pointer surface enter handling was:
1. update fouced surface
2. update the global position
On client side this resulted in:
1. Enter with incorrect coordinates
2. move event to correct coordinate
With QtWayland this results in the case of multiple surfaces in one
application that Qt doesn't properly process the enter event and the
Window never getting pointer focus and not reacting on any pointer
input events.
The root problem is that the KWayland server API is not ideal for
supporting this situation. There is an API call for setting the global
position (which causes a pointer motion for the focused surface) and
an API call to update the focused surface. But a combination for both
is (still) missing.
This change addresses the problem by first unsetting the entered surface,
then updating the global position and afterwards setting the new surface.
Thus the position is correct. While this needs to be made better in
KWayland, this is an urgency bug fix to get the behavior correct and thus
first working around the API deficit and not first extending in KWayland.
Reviewed-By: bshah
Summary:
If KWin fails to start the Wayland server due to XDG_RUNTIME_DIR not
being set, kwin_wayland should terminate with an error condition but
not crash.
This change makes sure that KWin detects that the Wayland server does
not work and terminates the startup early and ensures that it doesn't
crash while going down.
An error message is shown that we could not create the Wayland server.
Test Plan:
Test case added which verifies that WaylandServer fails to
init. Manual testing that kwin_wayland exits with error 1.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2078
Summary:
A new namespace KWin::Test is added which provides a few helper
functions. It makes it easy to setup a KWayland client connection with
the base set to be able to create a Surface and flags to create
additional interfaces. This replaces the KWayland connection dance in
init() methods. For cleanup() there is also a dedicated helper function.
In addition there are helper functions to:
* render a surface
* create a surface
* create a shell surface
* flush the wayland client connection
* access to the created interfaces - for compatibility with existing code
The idea is to extend this Test library also for other common use cases
like creating an X11 connection and X11 windows, etc.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2053
