From: "Lex Spoon" lex@cc.gatech.edu
I'm sure someone will post a more thorough response, but note that not all keys *have* an ASCII code. What is ASCII for F1, or up-arrow?
Several possible solutions:
1. Use Unicode instead of ASCII and define private characters for special keys 2. Assocate strings with the event and generate an equivalent escape-sequence (you still know that it was a single key because it comes in one event) 3. You still have the raw keyboard code...
AFAIK, MacOS-X/Cocoa does all of these at the same time.
Marcel
On Wed, 29 Nov 2000, Marcel Weiher wrote:
From: "Lex Spoon" lex@cc.gatech.edu
I'm sure someone will post a more thorough response, but note that not all keys *have* an ASCII code. What is ASCII for F1, or up-arrow?
Several possible solutions:
- Use Unicode instead of ASCII and define private characters
for special keys [...]
I'd prefer ...
1a. Use X key codes instead of ASCII so you do not have to define private characters for special keys
... as suggested by Andreas Raab. (Not quite) incidentally, these key codes include the ASCII characters at the usual code positions.
Here's (one instance of) the X11/keysymdef.h header file: http://src.openresources.com/debian/src/x11/HTML/S/ xfree86_3.3.2.2.orig%20xfree86-3.3.2.2.orig%20include%20keysymdef.h.html
-- Bert
From: Bert Freudenberg bert@isg.cs.uni-magdeburg.de
- Use Unicode instead of ASCII and define private characters
for special keys [...]
I'd prefer ...
1a. Use X key codes instead of ASCII so you do not have to define private characters for special keys
I don't see how this is an advantage, after all, the X keycodes essentially *are* private character definitions for special keys. The only difference between your proposal and mine that I can see is that with your proposal, codes may conflict with assigned Unicode codes, whereas with mine they cannot.
.... as suggested by Andreas Raab. (Not quite) incidentally, these key codes include the ASCII characters at the usual code positions.
So does Unicode. In fact, Unicode also has all the ISO characters at their usual/standard code positions. It also, not at all incidentally, has all the other Unicode standard characters at their standard positions, which sort of is the point ;-)
Marcel
The only difference between your proposal and mine that I can
see is
that with your proposal, codes may conflict with assigned Unicode codes, whereas with mine they cannot.
Good point. OTOH, inventing new codes just for the fun of it might not be clever. If we want to distinguish between characters typed and keys pressed/released (which I think we should do anyway) couldn't we use Unicode for the characters and X key syms for the keys?
Well, yes. However, I am not sure if having a "standard but non-standard" key-code is of much use, since you neither can be sure that the current device actually has a key-code that your app is looking for, nor that all the keys your device has actually map to one of the X keycodes.
I would think that the key-code should be whatever the device actually delivers (device-specific), because only then do you have a safe 1:1 mapping, whereas the same event also carries the unicode character (sequence) that is equivalent.
Marcel
On Thu, 30 Nov 2000, Marcel Weiher wrote:
Good point. OTOH, inventing new codes just for the fun of it might not be clever. If we want to distinguish between characters typed and keys pressed/released (which I think we should do anyway) couldn't we use Unicode for the characters and X key syms for the keys?
Well, yes. However, I am not sure if having a "standard but non-standard" key-code is of much use, since you neither can be sure that the current device actually has a key-code that your app is looking for, nor that all the keys your device has actually map to one of the X keycodes.
I think the keysym specs are extended when new keys bocome common. Like the Menu-key on Windows keyboards.
I would think that the key-code should be whatever the device actually delivers (device-specific), because only then do you have a safe 1:1 mapping, whereas the same event also carries the unicode character (sequence) that is equivalent.
But wouldn't it be better if, for example, the left shift key would produce the same key code on all platforms? The raw keyvalue (in my system an integer in the range 8-255, of which 105 are used because my keyboard has this many keys) might be useful for games, but you would have to have a special in-Squeak mapping for these codes ...
-- Bert
From: Bert Freudenberg bert@isg.cs.uni-magdeburg.de
But wouldn't it be better if, for example, the left shift key would produce the same key code on all platforms?
The problem here is that it doesn't. My system doesn't usually report left/right shift keys, it just gives me notification that shift is now pressed/unpressed, in addition to having the modifier flags set for other events.
The raw keyvalue (in my system an integer in the range 8-255, of which 105 are used because my keyboard has this many keys) might be useful for games, but you
would
have to have a special in-Squeak mapping for these codes ...
It seems to me that if you're going to do stuff like use 'left shift key' codes, you're going to be device-dependent anyhow, so pretending device-independence in any way shape or form is just asking for trouble.
Marcel
Peter asked me to forward this:
From: Peter Crowther Peter.Crowther@melandra.com Date: 2000-11-30 20:19:38 +0100
From: Marcel Weiher [mailto:marcel@metaobject.com] It seems to me that if you're going to do stuff like use 'left
shift
key' codes, you're going to be device-dependent anyhow
I'm with Marcel on this one. How do you cope with binding eg. the
Windows
keys, the Apple keys, the Amiga keys? And what do you do when
someone's
using a chord keypad, or the 'keyboard' on a PDA? I think the key
bindings
have to be device-dependent to allow extensions for each platform;
ideally,
though, you'd have pairs of <raw, Unicode-translated or nil> codes
coming up
from the VM as events, as the VM knows which platform it's running
on so it
can do the legwork where possible. Games programmers who don't
care which
key it is as long as the user presses it can use the raw code; business types the translated code.
- Peter
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Marcel Weiher