TextEvent proposal

Here is a set of proposals, following a discussion with Martin,
regarding TextEvent. An other message will follow to fix the set of
virtual key codes.

* clarifications:
 - text events happen after the FEPs(Front-End Process)/IMEs(Input-Event
 Methods) (including keydown/keyup)
   either the conversion result is sent to the application as a text
   event or single key that IMEs doesn't touch are sent to.
 - we need to add some general wording regarding differences between
 character generation system
* if the system only has one control key, there is no left and right.
  - both modifiers (left and right) are on.
* the order of META, CONTROL, SHIFT in the constant set should be
  harmonized.
  - we should probably say something about META since it is also used on
  Macintosh for the COMMAND key.
* if one key produced more than one unicode character
  (a composed character for example)
  - keyVal was meant to contain the unicode representation if any, but
  it can contain only unicode character (long). It should be 0 (no
  unicode character)
  - virtualKeyCode is 0 (the key does have a representation in Unicode).
  - so outputString will contain the 2 unicode
  characters. i.e. outputString should be used on keydown/keyup as
  well.
  (imho, we should keep keyVal to allow switch statements)
  we have the following changes:
  - textInput: keyVal could be 0 even if there a unicode representation.
   no changes on outputString since it was already used.
  - keydown/keyup: keyVal could be 0 even if there a unicode
    representation. outputString is now used to hold the unicode
    characters if any.
* if an unknown virtual key (i.e. no unicode representation) is produced
  (such as a Windows key, ...)
  virtualKeyCode is DOM_VK_UNDEFINED
  keyVal is 0 (it's a virtual key)
  outputString is null (it's a virtual key)
  - imho, we need to add back the keyCode field with a warning saying
  that this field is device dependent.

    so, when receiving a keydown/keyup:
    if [keyVal <> 0] {
      process the unicode character referenced by keyVal and check
      modifiers.
    } elif [outputString <> null] {
      process the string and check modifiers.
    } elif [virtualKeyCode <> DOM_VK_UNDEFINED] {
      process the known virtualKeyCode.
    } elif [keyCode <> 0] {
      // or <> -1, need to check with existing implementation.
      process the keyCode
    }
* some virtual key codes are missing, such as DOM_VK_HELP. The HELP key
  does not have a representation in Unicode and used to be part of
  KeyEvents.
  [cf separate message]

ISSUE: we decided recently to remove the constraint on having
keydown/keyup generated by pairs. Pbs:
- removing the constrain move us back in the device/platform dependent
area, i.e. you cannot count on keydown/keyup anymore since OS are really
incoherent on them. keydown will have to be avoided since it is not
generated at on Macintosh.
- Some OS generate a lot of keydowns when you keep pressing a key,
should we allow this or ask the implementation to remove/convert the
extra keydowns? (try to press SHIFT on Windows for example)

Philippe

Received on Wednesday, 2 October 2002 04:30:50 UTC