Differential D264

Handle tablet events ourselves
AbandonedPublic
Actions

Authored by abrahams on Aug 21 2015, 8:29 AM.

Details

Reviewers
dkazakov
rempt
Maniphest Tasks
T530: Fix tablet jitter
Summary

Do not enter Qt's tablet event loop after seeing a tablet event.

We are not bad for eating tablet events! Stand proud, believe in ourselves.

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped
abrahams updated this revision to Diff 596.Aug 21 2015, 8:29 AM
abrahams retitled this revision from to Handle tablet events ourselves.
abrahams updated this object.
abrahams edited the test plan for this revision. (Show Details)
abrahams added reviewers: dkazakov, rempt.
dkazakov edited edge metadata.Aug 21 2015, 9:00 AM

Hehe, sounds good! For the comment "Check if this is still the case in Qt5" you should check if clicking with any tablet buttons on the Right-click popup widget doesn't paint anything on a canvas.

abrahams updated this revision to Diff 597.Aug 21 2015, 9:27 AM
abrahams edited edge metadata.
abrahams removed R8 Calligra as the repository for this revision.

I wiped out the WM_ACTIVATE code and didn't see any drawing when opening and closing the popup palette with the side button on my tablet.

dkazakov added a comment.Aug 21 2015, 12:02 PM

Hi, Michael!

Could you also check the popup of the Advanced Color Selector docker (it should be activated in its settings manually, it shows up either on hover or on click). The tablet should be able to close it on click correctly and not paint anything on the canvas. If it works fine I'm ok with pushing this patch into frameworks :)

abrahams added a comment.Aug 21 2015, 12:15 PM

Yes, the color selection options dialog is capturing all tablet input - nothing gets sent to the canvas even if you try to draw on it.

dkazakov accepted this revision.Aug 28 2015, 9:06 AM
dkazakov edited edge metadata.

Looks ok to push

This revision is now accepted and ready to land.Aug 28 2015, 9:06 AM
rempt edited edge metadata.Aug 31 2015, 9:02 AM

Can we push this for now? I'm sure we'll be revisiting tablet support in the future, but I'd like to get ahead now.

abrahams planned changes to this revision.EditedAug 31 2015, 7:03 PM
In D264#5284, @rempt wrote:

Can we push this for now? I'm sure we'll be revisiting tablet support in the future, but I'd like to get ahead now.

It needs to be changed, it generates a segfault when moving from the canvas to the UI and back.

rempt added a comment.Sep 4 2015, 8:41 AM

I'm going to try and look at the input manager and tablet patches today, but I'm confused which ones I should apply...

abrahams abandoned this revision.Sep 5 2015, 1:47 PM

KisTabletSupportWin is going to be unused unless D270 completely falls through.

Revision Contents
Changeset List

Diff 597

View Options

krita/ui/input/wintab/kis_tablet_support_win.cpp

Loading...