On 9 May 2013 15:09, Hallvord R. M. Steen <hallvord@opera.com> wrote: > Siterer Wez <wez@google.com>: > > > In D3E the 'key' field indicates the meaning of the key in the current >> context, so in this case it would be appropriate for it to have distinct >> values for each of the cases listed. >> > > I disagree. This use case is fulfilled by the D3E "char" property, no? The > point of having the "key" property is to have a more stable reference to > whatever physical key was pressed. > No, that's what D4E 'code' provides, hence my mentioning it below. :) 'key' describes the meaning of the key in the context of the current keyboard layout, lock states and modifiers. If the user re-maps a key's meaning then 'key' will reflect that, whereas D4E 'code' wouldn't. 'char' conveys printable characters resulting from input, and in the presence of dead-keys, IMEs, etc, becomes meaningless on keydown or keyup events - it's been proposed that 'char' on those events be replaced by re-introducing 'textInput' events as per earlier D3E revisions. > > IMHO.. > > > The D4E 'code' field is intended to >> indicate the actual key that was pressed, regardless of its meaning in the >> current context, so that would be consistent for the spacebar, regardless >> of the generated KeySym. >> > > The question was about the interpretation of D3E though. > > > In this case I'd recommend: >> * For the "space" and "KP_Space" key-syms, generate Spacebar (NORMAL) and >> Spacebar (KEYPAD) events, respectively. >> * For the others, generate events using the corresponding Unicode code >> point for the 'key' field. >> > > And I would suggest that setting 'char' to the corresponding Unicode code > point and 'key' to "Spacebar' is the best way to fulfil all the various use > cases. > > -Hallvord > >Received on Thursday, 9 May 2013 23:47:46 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:02 UTC