Hide cursor when tablet stylus leaves proximity of the screen
AbandonedPublic

Authored by aacid on Jan 2 2019, 8:33 PM.

Details

Reviewers
sander
Group Reviewers
Okular
Summary

This patch fixes the following papercut: I regularly write on pdf files in presentation mode, using the styles that comes with my laptop. When I approach the screen with the pen, the cursor appears, and it follows the pen tip during writing. When I lift off the pen, the cursor stays on, and auto-hides only a few seconds later (because of Okular::Settings::EnumSlidesCursor::HiddenDelay). As a consequence, the cursor frequently hides the last bits of what I have just written. This is a nuisance.

With this patch, Okular catches the TabletEnterProximity and TabletLeaveProximity events. The former will make the cursor turn into a cross-hair; the latter will make it disappear directly, unless the cursor mode is 'always visible'.

There is one drawback to this patch. With the cursor mode HiddenDelay, the cursor disappears after a short time, and should reappear at the next mouse move. This does not work if the cursor has been hidden by TabletLeaveProximity, and I don't understand why. The patch therefore currently adds code to mouseMoveEvent that explicitly brings the cursor back. Any help on how to debug this (or an explanation of why it is necessary) is much appreciated.

Test Plan
  • Enter presentation mode
  • Approach the screen with a stylus. The cursor (appears if it was invisible before and) turns into a cross hair, before the stylus even actually touches the screen.
  • Remove the stylus again: if the cursor mode is Visible, the cursor turns into an arrow, otherwise it is hidden.

Diff Detail

Repository
R223 Okular
Lint
Lint Skipped
Unit
Unit Tests Skipped
sander created this revision.Jan 2 2019, 8:33 PM
Restricted Application added a project: Okular. · View Herald TranscriptJan 2 2019, 8:33 PM
Restricted Application added a subscriber: okular-devel. · View Herald Transcript
sander requested review of this revision.Jan 2 2019, 8:33 PM
ngraham added a subscriber: ngraham.Jan 2 2019, 8:39 PM

Very cool!

Coding style: Opening curly braces go on the same line of the if statement.

sander added a comment.Jan 2 2019, 8:45 PM

Coding style: Opening curly braces go on the same line of the if statement.

Not in that file, apparently.

aacid added a subscriber: aacid.Jan 2 2019, 10:02 PM

Coding style: Opening curly braces go on the same line of the if statement.

Not in that file, apparently.

Not in all of okular [exceptions probably exist]

aacid added inline comments.Jan 2 2019, 10:04 PM
ui/presentationwidget.cpp
1373–1375

Is this changeset related?

shubham added a subscriber: shubham.Jan 3 2019, 5:12 AM
shubham added inline comments.
ui/presentationwidget.cpp
540

Remove space before o

sander added inline comments.Jan 3 2019, 10:25 AM
ui/presentationwidget.cpp
1373–1375

It is. The code I added is exactly what the two calls to slotChangeDrawingToolEngine do, except that the first one additionally set the cursor to 'Arrow' (without good reason).

If you want this documented better then it may be a good idea to have it in a separate patch.

sander updated this revision to Diff 48589.Jan 3 2019, 10:30 AM

Whitespace fixes

sander marked an inline comment as done.Jan 3 2019, 10:30 AM
aacid added a comment.Jan 3 2019, 9:23 PM

There is one drawback to this patch. With the cursor mode HiddenDelay, the cursor disappears after a short time, and should reappear at the next mouse move. This does not work if the cursor has been hidden by TabletLeaveProximity, and I don't understand why.

Didn't we have this discussion millions of years ago? Maybe it was with someone else.

I Have two theories:
a) You're interfering with KCursor autohide, according to KCursor the cursor is still visible because it's you that set it to blank, not KCursor itself, so KCursor doesn't see a need to show it because it already thinks it's shown.
b) You need to call KCursos::autoHideEventFilter in your new event filter, see KCursor documentation https://api.kde.org/frameworks/kwidgetsaddons/html/classKCursor.html#ac667325a07f50c210d728d1ebddbcd06

ui/presentationwidget.cpp
1373–1375

ok

Didn't we have this discussion millions of years ago?

Yes, on ReviewBoard: https://git.reviewboard.kde.org/r/128858/

I've been using that patch happily ever since, but now I thought I'll have another try at upstreaming.

Your theories sound plausible, but don't seem to fix the problem. I'll try to dig a little deeper.

shubham removed a subscriber: shubham.Jan 4 2019, 2:57 PM

Hey, i just realized that i have a laptop with a touchscreen and a stylus and tried to test this to see if i could fix the missing bits.

But i never get the TabletEnterProximity/TabletLeaveProximity events.

I guess i have not configured the stylus properly?

Did you have to do something special so that it got detected?

stylus: https://www.lenovo.com/gb/en/accessories-and-monitors/pens-and-supplies/pens/TAB-ACC-BO-Pen-Pro-Yoga-460-P40-Yoga/p/4X80K32537

AFAIK these events are only generated for inductive styluses, because a capacitive touchscreen can’t detect proximity with acceptable quality, even less for a stylus.

So what kind of stylus/touchscreen do you use, @sander?

Albert, David, thanks for looking into this -- the problem seems to be a beyond my skill level. My hardware is a Lenovo Thinkpad Yoga, as in http://www.notebookreview.com/notebookreview/lenovo-thinkpad-yoga-12-review/ . I am not a stylus expert, said review calls it a "Wacom active pen stylus". I didn't have to do anything special to get it detected.

Not sure, but that one looks like the inductive stylus I once had. (That one worked pretty bad.)

Inductive coupling becomes better as the tip advances the screen surface. -> Proximity detection.
When the surface applies pressure to the tip, it squeezes an elastic element, which probably reduces resistance, which probably moves the resonance frequency. -> Pressure detection.

What would be new to me is that combinations of inductive touch & capacitive touch & illuminated color display exist. Cool.

So I can’t really help here.

I've been wondering whether it would be possible to write a unit test that sends out all the necessary events. That would allow to debug the problem without actually having the required hardware. Is that possible in principle?

Albert, how much would a suitable pen cost you? I offer to give you one as donation if that would help you finish this patch.

aacid added a comment.Jun 25 2019, 9:21 PM

Albert, how much would a suitable pen cost you? I offer to give you one as donation if that would help you finish this patch.

The pen i already have should work already, did you see the link i posted, it's probably the same one you have.

I just need to figure out how to set it up for it to be recognized as a pen and not as a mouse.

aacid added a comment.Jun 25 2019, 9:21 PM

I've been wondering whether it would be possible to write a unit test that sends out all the necessary events. That would allow to debug the problem without actually having the required hardware. Is that possible in principle?

Sure, that's very much possible and would be a great way to make sure things don't break in the future :)

sander added a comment.Jul 5 2019, 3:16 PM

With the help of Tobias (thanks!) I wrote a unit test. You can find it at https://invent.kde.org/kde/okular/merge_requests/9 .

aacid commandeered this revision.Jul 22 2019, 8:53 PM
aacid abandoned this revision.
aacid added a reviewer: sander.