Re: [w3ctag/design-reviews] Pen Events API (#553)

@kenchris @cynthia @atanassov thanks for your your patience.  Your originally posted questions slipped my attention.

RE: this comment from @kenchris and question 1 from @cynthia:
> Mouse has press and release events, but here you are only having a pressandhold, so you can not use it for pressing and dragging pen to select regions or text. Wouldn't it be better to have those instead?

[This section](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PenEvents/explainer.md#penbuttonclick-penbuttondblclick-penbuttonpressandhold-events) in the explainer covers why:
> Corresponding down/up events are not proposed because of hardware limitations, e.g. the Microsoft Surface Pen produces a signal describing the gesture, not the state transitions of the actual button.

RE: question 2 on the necessity of connect:
> Why is .connect() needed? Is this to ensure exclusive access to the pen, or a power saving measure?

The reason is explained in the [System Interactions section](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PenEvents/explainer.md#system-interactions):
> Note on some operating systems, pen events may trigger a default action. For example, on Windows, the shell provides configurable behavior for launching frequently used inking applications when pen button interactions are detected. Applications may register with the system to provide alternative behaviors and suppress the default behavior from the OS.
>
>For web applications, only active windows that have a connected `PenEventTarget` can override the system behavior. As a result, any internal registration required to ensure that a web app receives the proper events should take place any time the active window changes, or the set of connected `PenEventTarget`s change for the active window. The set of events to register is the unioned set of all events described by the `PenEventDescriptor`s of the connected `PenEventTargets` for the currently active window.

In Windows you can configure the behavior of the pen button events and opt to let apps override those behaviors.  The configuration UI looks like this:
<img src="https://user-images.githubusercontent.com/42626507/105978667-a8733880-6047-11eb-9da0-5a949e3dfbf3.png" width="450">

Calling `connect` on a `PenEventTarget` will cause the web page to register the `PenEventTarget`'s `PenEventDescriptors` with the system so that the web page can take over the events from the shell.

RE: question 3 on the need for a disconnect event:
> It feels like having a "disconnect" event will be useful, since devices (as far as we are aware) automatically disconnect and an application should be able to know if it needs to call connect() again.

The response to question 2 may have already made the purpose of connect more clear: connect isn't connecting to the pen, its registering the intent of the app to override system behaviors.  If the pen's bluetooth connection is interrupted, the web app doesn't need to call connect again.

RE: question 4 on blurred web pages with connected `PenEventTarget`s
> What happens when a page which is connected to a pen gets blurred?

I tried to cover that under the second paragraph of [System Interactions](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PenEvents/explainer.md#system-interactions)
> For web applications, only active windows that have a connected PenEventTarget can override the system behavior. As a result, any internal registration required to ensure that a web app receives the proper events should take place any time the active window changes, or the set of connected PenEventTargets change for the active window. The set of events to register is the unioned set of all events described by the PenEventDescriptors of the connected PenEventTargets for the currently active window.

Basically only `PenEventTarget`s for the active window will receive events.  On systems like Windows, the user agent must take care to return control to the shell when the active window changes (tab switches or you switch apps).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/553#issuecomment-768200381