"Raab, Andreas" wrote:
Folks,
After looking at Tim's EventSensor stuff I figured that there are a couple of things that I don't like (no pun intended). So I took a little time and rewrote it the way I think it should be done.
Looks good, from brief inspection. Haven't tried it out yet.
I like that you're sending key down and up events. However, I don't fully understand what they're supposed to be. Are you looking to have raw keycodes (OS specific)? Or just the same old (pre-mapped) codes from the VM?
I find the VM's mapping of keys to be a weak spot of the current implementation. There are a number of keys I just can't use, or that don't work the way I'd like (for instance, I don't seem to have a forward delete key in Squeak).
And I can't get raw key information (for instance, to differentiate between a keypad "1" and a main keyboard "1").
I wonder, also, what happens on key down events? Is there both a key down and a character event generated?
And what about keyboard auto-repeat? It's often distinguishable from the initial key press, at least at the OS level. You only have key down and up (as well as cooked char) events.
I'm still trying to figure out how to prevent the C support code from creating raw oops (another thing I don't like is that with Tims implementation you have to create oops yourself).
Why not just pass a ByteArray to the primitive and let it stuff in raw bytes instead of an Array (which you'd have to create oops for)?
Ned -
I find the VM's mapping of keys to be a weak spot of the current implementation. There are a number of keys I just can't use, or that don't work the way I'd like (for instance, I don't seem to have a forward delete key in Squeak).
Ctrl-delete gives you forward-delete (on the Mac, at least), as per (screen-menu / help... / command-key help). Its undo happens to be broken, though, in case anyone wants to fix it [I'm guilty -- put it in a couple of years ago when I didn't understand how the ParagraphEditor handles undo (still don't ;-)].
- Dan
Dan Ingalls wrote:
I find the VM's mapping of keys to be a weak spot of the current implementation. There are a number of keys I just can't use, or that don't work the way I'd like (for instance, I don't seem to have a forward delete key in Squeak).
Ctrl-delete gives you forward-delete (on the Mac, at least), as per (screen-menu / help... / command-key help). Its undo happens to be broken, though, in case anyone wants to fix it [I'm guilty -- put it in a couple of years ago when I didn't understand how the ParagraphEditor handles undo (still don't ;-)].
Well, yes it does!
However, I already have a forward delete key that I'm used to using (separate from my backspace key), and it wants to do the same thing as my backspace key.
(I'm using the Linux version of Squeak).
There is some suspicious code in sqXWindow.c, inside recordKeystroke that does this:
if (keystate == 127) keystate= 8;
In other words, if the key is Del (127), make it a backspace (8).
I suspect this is here because there is no hard and fast standard under Unix for what a Delete key emits (or the keypad DEL key either). Because of this, different people have their keyboards emit different characters. Some people have their backspace key output 127, while others have it output 8. And the Delete key generally outputs the other key value.
For that matter, the keypad DEL key often outputs yet another code. It's pretty ugly.
But XWindows is ugly anyway (and Unix GUIs are nowhere near consistent...).
I personally feel that the best place to handle this is in the X resources for the program (or perhaps with yet another command line switch?).
I'm going to remove those two little lines in my version, and suggest to the Unix VM folks that we consider an alternative (for those of us who already have the CORRECT keyboard mapping [1]).
[1] That is: the big key above the Return key (which on my (but not every) keyboard is labeled "Delete")) emits an 8, and the Del key emits a 127.
Ned Konz wrote:
Dan Ingalls wrote:
I find the VM's mapping of keys to be a weak spot of the current implementation. There are a number of keys I just can't use, or that don't work the way I'd like (for instance, I don't seem to have a forward delete key in Squeak).
Ctrl-delete gives you forward-delete (on the Mac, at least), as per (screen-menu / help... / command-key help). Its undo happens to be broken, though, in case anyone wants to fix it [I'm guilty -- put it in a couple of years ago when I didn't understand how the ParagraphEditor handles undo (still don't ;-)].
Well, yes it does!
However, I already have a forward delete key that I'm used to using (separate from my backspace key), and it wants to do the same thing as my backspace key.
(I'm using the Linux version of Squeak).
There is some suspicious code in sqXWindow.c, inside recordKeystroke that does this:
if (keystate == 127) keystate= 8;
In other words, if the key is Del (127), make it a backspace (8).
I suspect this is here because there is no hard and fast standard under Unix for what a Delete key emits (or the keypad DEL key either).
The definition for ASCII says, that 8 -> BS, and 127 -> DEL.
Because of this, different people have their keyboards emit different characters. Some people have their backspace key output 127, while others have it output 8. And the Delete key generally outputs the other key value.
For that matter, the keypad DEL key often outputs yet another code. It's pretty ugly.
I think we should rely onto the standard here.
But XWindows is ugly anyway (and Unix GUIs are nowhere near consistent...).
I personally feel that the best place to handle this is in the X resources for the program (or perhaps with yet another command line switch?).
I'd prefer a line switch, if necessary (means: somebody wants to have one): This should be more platform independent as an X resource file.
I'm going to remove those two little lines in my version, and suggest to the Unix VM folks that we consider an alternative (for those of us who already have the CORRECT keyboard mapping [1]).
Probably we need some changes in the ST code, too, to handle the 'new' key code; isn't it?
[1] That is: the big key above the Return key (which on my (but not every) keyboard is labeled "Delete"))
?
for me it is labeled '<---'...
emits an 8,
BS,
and the Del key emits a 127.
How it is labeled at your keyboard?
Stephan
Stephan Rudlof wrote:
The definition for ASCII says, that 8 -> BS, and 127 -> DEL. I think we should rely onto the standard here.
Fine with me. So why does the code map DEL into BS?
Probably we need some changes in the ST code, too, to handle the 'new' key code; isn't it?
No, it works fine if you remove the code that maps 127->8. ST knows about DEL and does the right thing (forward delete).
and the Del key emits a 127.
How it is labeled at your keyboard?
Well, I have a very compressed keyboard (the PFU Happy Hacking Keyboard Lite) that lets you juggle the keyboard layout. So the key marked "Delete" I have generate a BS, and the key that is marked Del generates a DEL. You have choices, though.
See http://www.pfuca.com/products/hhkb/litelayout.html for its layout.
On Sat, 29 Jul 2000 15:40:17 -0700, Ned Konz ned@bike-nomad.com wrote:
I find the VM's mapping of keys to be a weak spot of the current implementation. There are a number of keys I just can't use, or that don't work the way I'd like (for instance, I don't seem to have a forward delete key in Squeak).
In 2.7 under Windows, you need to use Shift-Backspace. In the 2.8 image & VM I downloaded, the Delete key works as it should, and shift-backspace does word-delete or something like that.
Later, Jon
-------------------------------------------------------------- Jon Hylands Jon@huv.com http://www.huv.com/jon
Project: Micro Seeker (Micro Autonomous Underwater Vehicle) http://www.huv.com
squeak-dev@lists.squeakfoundation.org