-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stylus eraser: should it be a new pointerType instead of a button state? #134
Comments
I think the spec only talks about buttons in the location that a standard pencil's eraser would be in, not about pens that have been inverted to use as an eraser. I agree that it makes sense to treat an inverted stylus that supports the flipped behavior as being a different pointer type. |
Interesting. Maybe the biggest question here is "should pressing the eraser button be distinguishable from using a pen inverted". I assume there are art use cases where the user does really expect for these to be different operations, right? Does anyone know if apps like Photoshop these differently today? If we did introduce a new "eraser" |
(accidentally answered by email on the PEWG list rather than here/to the github email, so copying the relevant part of my message) I admit to not having played around with this too much with my Wacom tablet, but fundamentally I would still perceive the pen as being a single "pen" type even when flipped. Whether it's a flipped pen (like the Wacom stylus) or the pen in the same orientation but with the eraser button pressed (like on the Surface) seems more of a skeuomorphic gimmick / usability issue to me...the end result is still that the user wants to erase something with their pen. I'm not sure if there are pens that have BOTH an eraser button AND can be used inverted. |
I completely agree that from the usability standpoint, it should behave as a single pen. But the "active button state" is what gives me worries, see below...
Again, I agree that for both cases, the user wants to erase something. The follow-up action is more important here: when should the user start to erase something? I argue that erasing while hovering seems too destructive, erasing should start only when the pen is touching the surface. |
To clarify the current behavior:
(and for this scenario i think it'd be overkill to invent a whole new |
oh i should probably clarify i'm testing here using https://patrickhlauke.github.io/touch/tracker/multi-touch-tracker-pointer-hud.html in Edge |
I tested the low-level events from a Wacom Intuos Pro through Pixel evtest tool. A flipped ("eraser mode") pen appears as BTN_TOOL_RUBBER even when hovering. @patrickhlauke: Does your test above use the same Wacom digitizer? |
Yes, Wacom Intuos Pro with default stylus |
Cross-posting Dave Fleck's response on the mailing list https://lists.w3.org/Archives/Public/public-pointer-events/2016JulSep/0290.html here:
|
So if I understand the current situation correctly: in Windows/Edge, erasing has been implemented/forced as a modifier key that's tied specifically to pressure on the digitizer (in the case of the Surface Pen, pressing eraser button while hovering has no effect, and it only acts as modifier once the tip touches the screen; in the case of the Wacom stylus, having the stylus flipped - which at low level is distinguished as being an "eraser mode" switch - has no effect, and the hovering eraser is treated exactly the same as a hovering writing tip, and only once the eraser has any pressure it's translated into a pen action with eraser modifier). The question for me is: are Microsoft likely to change the model and treat the eraser button not as a modifier, but as a means of switching into "eraser mode", changing the @teddink any thoughts? |
also, based on dave's other message concerning USI https://lists.w3.org/Archives/Public/public-pointer-events/2016JulSep/0293.html
would this mean that instead of doing any special-casing with (and to clarify, this would probably then mean removing any notion of "erase button" itself from |
Cross-posting Dave Fleck's recent response that I missed:
|
Just realized that @RByers's questions went unanswered. I will draw others attention through my two cents:
If a pen has both an eraser button and a flipped eraser mode, IMO it's the job of the driver/OS to let us distinguish between them. I think @patrickhlauke once posted a screenshot of Wacom settings which even allows associating a button to "touching the screen", right? An analogous example for mouse: if the OS lets users define simultaneous L+R click as a middle button (Linux used to support this for two button mouse), an WebApp perhaps shouldn't care.
Right now, both Edge & Chrome emits a new pointerId if the same pen leaves-then-enters the digitizer range. We can safely do the same for a flipped pen, right? |
so what would happen if a stylus is either hovering or touching the digitizer, and then the eraser barrel button is pressed? does it need to pretend that the pen left (so firing off |
I see that pointerType="eraser" model will have to pretend pen leaving-and-entering, which will be terrible! Thanks for the catch.
It seems to me that adding a Boolean property
|
The PointerEvent spec can't gracefully support a hovering pen in eraser mode because a non-zero |buttons| field indicate an active buttons state. The issue is currently being discussed in github: w3c/pointerevents#134 Until the spec gets fixed, this CL exposes the eraser mode in a spec-compliant way by hiding the eraser mode until the pen touches the digitizer. Edge shows the same behavior. This CL also adds X1, X2 & Eraser button/buttons values to WebPointerProperties. BUG=642455 Review-Url: https://codereview.chromium.org/2296303002 Cr-Commit-Position: refs/heads/master@{#416360} (cherry picked from commit 758b115) Review URL: https://codereview.chromium.org/2313653004 . Cr-Commit-Position: refs/branch-heads/2840@{#168} Cr-Branched-From: 1ae106d-refs/heads/master@{#414607}
… (patchset #1 id:1 of https://codereview.chromium.org/2313653004/ ) Reason for revert: Broke the build. Original issue's description: > Make a pen in eraser mode visible thru PointerEvent.buttons > > The PointerEvent spec can't gracefully support a hovering pen in eraser > mode because a non-zero |buttons| field indicate an active buttons > state. The issue is currently being discussed in github: > w3c/pointerevents#134 > > Until the spec gets fixed, this CL exposes the eraser mode in a > spec-compliant way by hiding the eraser mode until the pen touches the > digitizer. Edge shows the same behavior. > > This CL also adds X1, X2 & Eraser button/buttons values to > WebPointerProperties. > > BUG=642455 > > Review-Url: https://codereview.chromium.org/2296303002 > Cr-Commit-Position: refs/heads/master@{#416360} > (cherry picked from commit 758b115) > > Committed: https://chromium.googlesource.com/chromium/src/+/956dc72f92984d993e390491c90b283beda8b89c TBR= # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=642455 Review-Url: https://codereview.chromium.org/2314093002 Cr-Commit-Position: refs/branch-heads/2840@{#170} Cr-Branched-From: 1ae106d-refs/heads/master@{#414607}
The PointerEvent spec can't gracefully support a hovering pen in eraser mode because a non-zero |buttons| field indicate an active buttons state. The issue is currently being discussed in github: w3c/pointerevents#134 Until the spec gets fixed, this CL exposes the eraser mode in a spec-compliant way by hiding the eraser mode until the pen touches the digitizer. Edge shows the same behavior. This CL also adds X1, X2 & Eraser button/buttons values to WebPointerProperties. BUG=642455 Review-Url: https://codereview.chromium.org/2296303002 Cr-Commit-Position: refs/heads/master@{#416360} (cherry picked from commit 758b115) Review URL: https://codereview.chromium.org/2311213004 . Cr-Commit-Position: refs/branch-heads/2840@{#179} Cr-Branched-From: 1ae106d-refs/heads/master@{#414607}
It seems pointerType="eraser" model is not as terrible as I commented above, see Dave Fleck's reply in the list. |
(adding this here from discussion thread) Here’s the Windows requirement that the pen leave and re-enter in eraser mode - from: While the pen is within detection range of the digitizer, but not in contact with the screen, activation/deactivation of the erase affordance should be honored. However, direct transitions between the "Pen is in range" and the "Pen is in range with intent to erase" states are not supported, and in this scenario, the pen states must always transition via "Pen is out of range." |
Due to lack of momentum (or implementation) on this, marking this as a potential future/v3 feature |
I don't think there's much appetite/movement on this even for v3. Current state of play - based on testing with Surface at least - seems to be that there's no differentiation between a stylus writing and erasing in terms of Propose closing this. |
@BoCupp-Microsoft, we're thinking to close this issue. |
Sorry for chatting on such an old topic, but am I correct in saying that since this ticket is still open, the standard has no official way to get whether a pen tablet or pen input is an eraser without checking button state? Sorry if this is noise, but I've been googling for the last couple hours and this is the most relevant answer I could find from either google or duckduckgo. I'm building a silly webapp for my wacom screen tablet and not distinguishing pointer "pen" from "eraser" is giving me a hard time. The only documentation I've been able to find has been from: https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/mozInputSource Which is, well, non-standard. So if someone was willing to pick this up, as a developer trying to use the raw api's, adding an eraser pointer-type would be real nice. Edit: After investigating it, I could find no way of telling if my pen is flipped and thus swapped to an 'eraser' mode. |
i personally still think we could/should consider an actual eraser pointer type, as the current approach of just identifying "presses" that are with the eraser ( once v3 is out of the door, i'd really like to flesh this out some more and see if there could be renewed appetite from implementers to actually support it. |
I couldn't locate the motivation in the spec for treating "eraser" as a button state instead of a pointerType. Have we ever considered adding a new pointerType="eraser"?
Below are my thoughts about why pointerType="eraser" seems to be a better idea. To ease the discussion, I will use "eraser mode" to mean the physical orientation of a pen that is flipped to become an eraser, and "pencil mode" to mean the pen's normal orientation. (If the pen doesn't allow the flipped orientation but has a "eraser" button instead, my points still hold although a bit weakly.)
Consider a pen that is switched from "pencil" to "eraser" mode while hovering. Even though our recent spec change supports hovering pen buttons, this state of the pen seems awkward in quite a few different ways:
A. This is in "active button state" which is conceptually a stronger state than just an "active state". E.g., the pointer can now be captured. The analogous state for a "pencil" mode is only "active state" and not "active button state". An eraser is intuitively a destructive mode, so should never have a stronger effect than the corresponding "constructive" mode IMO.
B. At the moment of the flip to the eraser mode, if the pen stayed within the range of the digitizer, the pen moved from "inactive" to "active button state". The current spec wording means the UA needs to fire a
pointerdown
. So, one could click a button by just flipping to eraser mode!C. If the pen momentarily moves away from the digitizer range during the flip to the eraser mode, it can possibly feel like a new stylus device with a button already pressed. If that is the case, will the very first event be a
pointermove
and not apointerdown
because the new device never switched its button state? This is a corner case for hovering buttons that we narrowly missed.A quick web search reveals we have examples to support the change: many (most?) low (OS/device) level APIs treat eraser mode as a new device type similar to mouse/pen. Examples:
The text was updated successfully, but these errors were encountered: