Re: Actions questions

On 09/05/16 17:06, James Graham wrote:
> Summary of my thinking with the protocol at the moment (as much for my
> reference as anything):
>
> <ActionsCommand>
> {
> actions: [<ActionSequence>]
> }
>
> <ActionSequence>:
> {
> id: String, # Device id
> type: "key" | "pointer", # Type of actions in this sequence
> actions: [(<KeyAction>|<PointerAction>)|<GeneralAction>]
> }

So I have been reading the pointer events spec a little, and I have the 
outline of a proposal for a better model here.

Redefined <ActionSequence> so it has an optional "parameters" attribute 
that defines device-specific parameters. For pointer actions this would 
take a "pointerType" attribute with one of the values "mouse", "pen" or 
"touch". For now "pen" and "touch" would be alike (except that the value 
would be reflected in the pointer events generated), but future 
evolution of the standard would likely lead to differences between them 
to account for the richer featuresets of pens compared to fingers.

As an aside, for key actions, I anticipate that the "parameters" 
attribute would be used in the future to specify the keyboard layout to 
use for translating characters to key codes.

The difference between "mouse" and other pointer types that we would 
only generate mouse events for the mouse pointer type. This is different 
to the pointerEvents model where mouse events are generated for any kind 
of device that is marked as "primary". I suppose we could directly 
follow that spec here, and add a second parameter to indicate if a 
device is primary or not, if people feel it's important to be able to 
generate mouse events from e.g. a touch pointer event.

In addition, I believe we should allow the device id to be 
optional/null, in which case the implementation will generate a uuid for 
the device, which will be returned from the command (see below).

> <PointerDownAction>:
> {
> type: "pointerDown"
> button: Integer # Button number
> }
>
> <PointerMoveAction>:
> {
> type: "pointerMove"
> optional x: Integer | Null # Coordinates to move to relative to the
>                             # active element. Need an origin member?
> optional y: Integer | Null
> }

I think that it doesn't make sense to use the active element as an 
offset for the coordinates in these actions, because one can reasonably 
move the pointer to a location that can't take tab focus. Therefore I 
think it's necessary to provide this element explicitly as part of the 
action. If we allow the element to be missing, there are two options; 
set the coordinates relative to the last position of the pointer (it is 
unclear what to do if this is the first action and so the position is 
unknown), or set the coordinates relative to the viewport. I think I 
prefer the option to let it be missing and make it possible to set 
coordinates relative to the viewport. This would allow a mode of 
operation in which it was possible to avoid implicit scrolling.

So far I think the actions parameters don't return anything. That seems 
suboptimal from the client point of view. I think I would like to return 
at least the device id for each action sequence, and maybe a 
device-specific state object indicating e.g. which keys are in a 
depressed state. Does anyone have specific use cases for the return 
value of this command?

Received on Wednesday, 11 May 2016 10:58:19 UTC