------------------------------ Hello Lex and all,
Thanks for reply. I am working on Win XP Professional, Squeak 3.6 Full. For me even after setting duplicateControlAndAltKeys, Ctrl+P, Ctrl+D don't work. I think all Alt Keys short cut should work with Ctrl. but Ctrl+C, Ctrl+V, Ctrl+X and Ctrl+Z are working perfectly fine. Also, Home and End keys for navigation with Ctrl is not working the same way they work for Alt. Like Alt+end goes to end of file but Ctrl+end doesn't. Ctrl+home goes to first like but selects text(don't know why, this should only happen if shift is pressed). I think this functionality is either has bugs or nobody bother to give it. but for someone who is coming from Windows editiors it's bit of pain, to move to alt keys from ctrl.
Hope someone will fix these bugs for Squeak 3.6 (Full) on Windows XP. Thanks in Advance.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
Original message by Lex:
Do you mean the dupAllKeys changeset? If so, then it's a design decision. Squeak cannot tell the difference between ctrl-C and ctrl-enter, and I decided that ctrl-C ("copy") is much more important. To allow both key sequences requires changes to all the VM's.
I don't know what you mean about ctrl-p and ctrl-d. They work for me. What OS are you using? I'm on Linux.
I should mention that I'm using Squeak 3.6, in case that matters.
-Lex
Message: 28 Date: Thu, 30 Oct 2003 17:49:26 -0400 From: "Lex Spoon" lex@cc.gatech.edu Subject: Re: duplicateControlAndAltKeys To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Message-ID: E1AFLtz-0005gY-03@logrus.dnsalias.net
"Pravin A. Sable" pravin@ccs.neu.edu wrote:
duplicateControlAndAltKeys setting doesn't seems to be working for certain keys. Like Home and End keys in combination with Ctrl. This keys works perfectly fine with Alt keys. Also, commands like Alt+P, Alt+D doesn't work for Ctrl+P, Ctrl+D. I think this is either bug or
unfinished
functionality. Hope someboy among squeak community will help me in
this.
"Pravin A. Sable" pravin@ccs.neu.edu wrote:
Thanks for reply. I am working on Win XP Professional, Squeak 3.6 Full. For me even after setting duplicateControlAndAltKeys, Ctrl+P, Ctrl+D don't work. I think all Alt Keys short cut should work with Ctrl. but Ctrl+C, Ctrl+V, Ctrl+X and Ctrl+Z are working perfectly fine. Also, Home and End keys for navigation with Ctrl is not working the same way they work for Alt. Like Alt+end goes to end of file but Ctrl+end doesn't. Ctrl+home goes to first like but selects text(don't know why, this should only happen if shift is pressed). I think this functionality is either has bugs or nobody bother to give it. but for someone who is coming from Windows editiors it's bit of pain, to move to alt keys from ctrl.
It is impossible, short of changing the VM, to have Ctrl-End and Ctrl-D do different things. They have to perform the same function. So for now, the choice is simply which function that should be. In dupAllKeys, I picked in favor of "do-it".
Clearly this can cause trouble, but it requires VM tweaking to do any better. The simplest VM tweak would be if things like ctrl-d came in as "control plus d" instead of "control plus control-d".
-Lex
It is impossible, short of changing the VM, to have Ctrl-End and Ctrl-D do different things.
That, of course, is wrong. The reason why these are processed in the same way is that all current clients use *character* events (which implies an ascii representation) instead of *key* events (which implies a key pressed on a particular keyboard). And since the ascii range is filled with lots and lots of useful ascii characters there is simply not enough room to fit all of the different key events in there. Try checking the key-down events instead - I'm pretty sure those will be different.
Clearly this can cause trouble, but it requires VM tweaking to do any better.
Nope. All it requires is to use untranslated keyDown events instead of (translated) characters ;-)
Cheers, - Andreas
"Andreas Raab" andreas.raab@gmx.de wrote:
It is impossible, short of changing the VM, to have Ctrl-End and Ctrl-D do different things.
That, of course, is wrong. The reason why these are processed in the same way is that all current clients use *character* events (which implies an ascii representation) instead of *key* events (which implies a key pressed on a particular keyboard). And since the ascii range is filled with lots and lots of useful ascii characters there is simply not enough room to fit all of the different key events in there. Try checking the key-down events instead - I'm pretty sure those will be different.
Well, I made a proposal buried back in the depths of the thread. Encode control+a as "a plus control" instead of "control-a plus control". I see no lossage from this encoding and it would solve the immediate problem.
Nope. All it requires is to use untranslated keyDown events instead of (translated) characters ;-)
Oh, that's very nice, you can handle keyDown: and keyUp: and get the raw events. Is it intended that these keystrokes are the same across platforms when possible? For example, is it intended that End and Copy are the same on all platforms that have them?
As it stands, it looks like this facility is not implemented very well at least on Unix. For example, I tried this code:
buf := OrderedCollection new. [ buf size < 10 ] whileTrue: [ evt := Sensor nextEventFromQueue. evt ifNotNil: [ buf add: evt ] ]. buf
Then I pressed ctrl-end and then ctrl-d and then waved the mouse around. The events I see are the following:
#(2 447859143 112 2 8 0 0 0) #(2 447864587 4 1 2 0 0 0) #(2 447864587 4 0 2 0 0 0) #(2 447864687 4 2 2 0 0 0) #(2 447865692 4 1 2 0 0 0) #(2 447865692 4 0 2 0 0 0) #(2 447865824 4 2 2 0 0 0) #(1 447867771 509 289 0 0 0 0) #(1 447867787 509 301 0 0 0 0) #(1 447867795 509 311 0 0 0 0))
The type 2's are keystroke events of various flavors. The second field is a timestamp. Looking at generateKeyboardEvent:, I see that the other fields are:
3 value 4 pressType (either keyDown (1), keyUp (2), or keystroke (0)) 5 modifiers
So, I see alt-d being released, and then the other 6 key events all have value "4". The control key itself doesn't generate any events. It would be interesting whether this has been implemented differently on other platforms.
I've mentioned before, though maybe not on the list, that the XWindows list of key symbols might be worth re-using in Squeak for the purpose of encoding these values.
-Lex
On Saturday 01 November 2003 11:30 am, Lex Spoon wrote:
I've mentioned before, though maybe not on the list, that the XWindows list of key symbols might be worth re-using in Squeak for the purpose of encoding these values.
We do use these symbols in the VM to translate the incoming X11 events into Squeak keystrokes.
Hi Lex,
Well, I made a proposal buried back in the depths of the thread. Encode control+a as "a plus control" instead of "control-a plus control". I see no lossage from this encoding and it would solve the immediate problem.
It may solve the immediate problem but conceptually this is very wrong since (assuming that the VM does any character translation at all) the combination of the (physical) key strokes "control + A" _should_ result in control-A. If we start going down this path, then we essentially "untranslate" the VM translation efforts (which seems pointless to me) and may introduce many other ugly idiosynchracies. So it seems better to use what the VMs are providing anyway - untranslated keyDown/keyUp events for determining "raw" key strokes and using keyStroke events for the "composed" characters.
Oh, that's very nice, you can handle keyDown: and keyUp: and get the raw events. Is it intended that these keystrokes are the same across platforms when possible?
We talked about this in the past and didn't come to an ultimate solution.
For example, is it intended that End and Copy are the same on all platforms that have them?
That would definitely be the best solution though I am not certain all of the different keyboards will agree on what the "same" keys are ;-) But it's worth to shoot for it.
As it stands, it looks like this facility is not implemented very well at least on Unix. For example, I tried this code:
buf := OrderedCollection new. [ buf size < 10 ] whileTrue: [ evt := Sensor nextEventFromQueue. evt ifNotNil: [ buf add: evt ] ]. buf
Then I pressed ctrl-end and then ctrl-d and then waved the mouse around. The events I see are the following:
Here's the equivalent on Windows:
#(2 14686478 17 1 2 0 0 0) "ctrl down" #(2 14686688 68 1 2 0 0 0) "D down" #(2 14686688 4 0 2 0 0 0) "ctrl-D" #(2 14686798 68 2 2 0 0 0) "D up" #(2 14686828 17 2 0 0 0 0) "ctrl up"
#(2 14687589 17 1 2 0 0 0) "ctrl down" #(2 14687789 4 1 2 0 0 0) "end down" #(2 14687789 4 0 2 0 0 0) "ctrl-end" #(2 14687870 4 2 2 0 0 0) "end up" #(2 14687950 17 2 0 0 0 0) "ctrl up"
So, I see alt-d being released, and then the other 6 key events all have value "4".
That seems wrong to me.
The control key itself doesn't generate any events.
That too.
I've mentioned before, though maybe not on the list, that the XWindows list of key symbols might be worth re-using in Squeak for the purpose of encoding these values.
If someone sends me a comprehensive list of these values I'd be happy to make the VM conform to these.
Cheers, - Andreas
I've mentioned before, though maybe not on the list, that the XWindows list of key symbols might be worth re-using in Squeak for the purpose of encoding these values.
If someone sends me a comprehensive list of these values I'd be happy to make the VM conform to these.
Okay, I've posted the list here:
"Key Events" http://minnow.cc.gatech.edu/squeak/3503
Of course, implementing this on XWindows would be rather trivial even though it's not done right now. :)
-Lex
"Lex Spoon" lex@cc.gatech.edu wrote:
Nope. All it requires is to use untranslated keyDown events instead of (translated) characters ;-)
Oh, that's very nice, you can handle keyDown: and keyUp: and get the raw events. Is it intended that these keystrokes are the same across platforms when possible? For example, is it intended that End and Copy are the same on all platforms that have them?
It would be lovely if it could be true but different OSs have different approaches and it can be very difficult bordering on impossible to get everything the same. For example, RISC OS simply doesn't give you key up and downs in the GUI interface. It _will_ provide ultra-low level events for that sort of thing but you have no idea if the event really applies to your particular application. _Very_ annoying.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim One if by LAN, two if by C. - Paul Revere, as told by John Karwoski
It would be lovely if it could be true but different OSs have different approaches and it can be very difficult bordering on impossible to get everything the same. For example, RISC OS simply doesn't give you key up and downs in the GUI interface.
I find this hard to believe. All modern GUIs recognize the difference between a character (which may even result from a series of key strokes such as for accented characters) and the actual keys pressed.
It _will_ provide ultra-low level events for that sort of thing but you have no idea if the event really applies to your particular application. _Very_ annoying.
Well, you could keep track of whether your application is the "active" app (depending on the means of your OS) and report these ultra-low level events only if the app is active. This will probably do the trick.
Cheers, - Andreas
"Andreas Raab" andreas.raab@gmx.de wrote:
It would be lovely if it could be true but different OSs have different approaches and it can be very difficult bordering on impossible to get everything the same. For example, RISC OS simply doesn't give you key up and downs in the GUI interface.
I find this hard to believe. All modern GUIs recognize the difference between a character (which may even result from a series of key strokes such as for accented characters) and the actual keys pressed.
Oh, believe me, I've tried. RISC OS can do the very low-level and the very high (ie your button id#54 got a double-click) but anything in between isn't there. I do have someone inside the OS team that claims they are working on it for me.... Real Soon Now.
It _will_ provide ultra-low level events for that sort of thing but you have no idea if the event really applies to your particular application. _Very_ annoying.
Well, you could keep track of whether your application is the "active" app (depending on the means of your OS) and report these ultra-low level events only if the app is active. This will probably do the trick.
I thought so once upon a time. Tried it a dozen ways to hell and it simply didn't work. Hope fully the above mentioned insider can solve my problem.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Memory dump: Amnesia...
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Lex Spoon -
Ned Konz -
Pravin A. Sable -
Tim Rowledge