Add Wayland touch drag and drop support
ClosedPublic

Authored by romangg on Sep 12 2018, 8:33 PM.

Details

Summary

Use the new functionality in KWayland to support drag and drop via touch
screens.

Either a drag and drop session with pointer or touch is possible, but not
both at the same time. Pointer/touch gets deactivated if a touch/pointer
drag and drop session is active.

Test Plan

Manually.

Diff Detail

Repository
R108 KWin
Branch
touchDragSupport
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 3001
Build 3019: arc lint + arc unit
romangg created this revision.Sep 12 2018, 8:33 PM
Restricted Application added a project: KWin. · View Herald TranscriptSep 12 2018, 8:33 PM
Restricted Application added a subscriber: kwin. · View Herald Transcript
romangg requested review of this revision.Sep 12 2018, 8:33 PM
romangg updated this revision to Diff 41924.Sep 19 2018, 12:41 AM

Rebase on InputDeviceHandler focus tracking rework.

alexde added a subscriber: alexde.Oct 26 2018, 9:54 AM

Autotest planned.

Did anything come of this?

input.cpp
1521

So we base the ID of the touch performing the drag based on the first movement after a client creates a grab.

Is that safe?

We know the serial in dragStarted can we take the touch ID from d->globalTouch.ids.key(serial) and then expose that in SeatInterface?

1536

should this come after we activate the client?

romangg added inline comments.Nov 7 2018, 4:26 PM
input.cpp
1521

Isn't that what the comment below is about? Where do you see a problem in regards to safety? The ID is only used to specify the drag performing touch point while the touch sequence is ongoing.

1536

I have either argument for or against it. I tested it this way and it worked.

davidedmundson requested changes to this revision.Nov 7 2018, 4:28 PM
davidedmundson added inline comments.
input.cpp
1521

one could press two fingers, one starts a drag then they move the second

This revision now requires changes to proceed.Nov 7 2018, 4:28 PM
romangg added inline comments.Nov 7 2018, 4:55 PM
input.cpp
1521

And where do you see a problem in regards to safety? The comment below indicates that this is a corner case I deemed not to be important in this first implementation of touch drag and to be looked into later.

So is there a safety issue, which would then of course make it important? As it is now it would just use in this unlikely event the other touch point as "anchor" of the drag.

Autotest planned.

Did anything come of this?

I added an autotest to KWayland in D15464. KWin currently misses integration tests for dnd in general. We should look into this mid-term, then build test functionality for general inter-client communication (all clipboard, dnd and in the future primary selection protocol).

romangg edited the test plan for this revision. (Show Details)Nov 9 2018, 10:56 AM
This revision was not accepted when it landed; it landed in state Needs Revision.Dec 2 2018, 8:55 PM
This revision was automatically updated to reflect the committed changes.