We lost information when using QMouseEvent::globalPos, since
it is integer. Use instead InputRedirection::globalPointer,
which is updated before the filters are processed and is
float.
Details
- Reviewers
davidedmundson - Group Reviewers
KWin - Commits
- R108:b5a91cdfe08c: Float position values in drag input filter
Manually.
Diff Detail
- Repository
- R108 KWin
- Branch
- dragPointFPos
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 2849 Build 2867: arc lint + arc unit
I saw one potential problem, you can clarify if it's relevant. If event is someone that resend with different position that current one, as i can see input()->globalPointer() will result in current position which can be different from event position, do you think?
Thanks for taking a look at it.
The filters are run through always directly after each event. In this case the relevant code is in pointer_input.cpp: PointerInputRedirection::processMotion, where m_pos is set by a call to PointerInputRedirection::updatePosition. Since this happens directly before every filter run on mouse move, the position is the same.
Yeah, i see they are in sync but if someone sends adjustment events who contain not a *real* mouse position like these https://phabricator.kde.org/source/plasma-workspace/browse/master/shell/panelview.cpp$839 Is this can be a problem>
Where should these events originate from? The filters are run through directly afterthey comes from the PointerInputRedirection, which bases the position value on a hardware position. KWin is the compositor, so it does not receive hardware events from its clients.