This component defines nodes to interact with a keyboard.
KeySensor processes simple key presses / releases.
StringSensor provides a simple way for user to type and edit
For demos and tests of these features,
sensors_key subdirectory inside our VRML/X3D demo models.
TODO: for now, only 8-bit ASCII characters are passed
and to the
actionKeyPress events follow
the "key repeat" feature of your operating system/window manager.
This means that when the user holds down a key, we generate many key press events.
Sometimes it's useful (for simulating normal text input, for example).
Report if you would like to make this feature optional (and maybe
off by default?), a field like
KeySensor.repeatKey may be added.
isActive := TRUE is also generated at each key press,
isActive := FALSE at each key release. So they do not match in pairs.
And it's not that simple, even if we would turn off the "key repeat" feature
mentioned above: imagine that you press one key, then you press a 2nd key,
and release the 1st key. Turns out that we have to track all the keys pressed,
and deactivate only when all are released, right? Things get more hairy
when you consider the first key to be the letter "a", and the 2nd key to be "Shift".
Conceptually, "a" is pressed, then "A" is pressed, then "A" is released...
but when was lower-case "a" released?
Actually, we do have a smart code inside an engine to track it correctly,
but it's not passed to the
StringSensor) may be active at given time. The specification
doesn't precisely say what should happen, with wording suggesting
that making a sensor enabled makes it also active (which contradicts the
spec), and without saying which sensor is chosen if many are present (the first?
the last in the graph?).
KeySensor is in fact the first sensor node implemented long time ago :)