ctrl+a is seen as ctrl+home windows
Hi, I am on Windows, using Pharo 3.0, and I am trying to get the keybindings to work in Rubric using Windows convention (so, Ctrl instead of Cmd as a modifier), It worked reasonably well, but the problem is that somehow Ctrl+a is mapped to Ctrl+Home. The problem is not specific to Rubric as I can detect the same behavior in the regular PluggableTextMorph. Does anyone have an idea of where the problem comes from? Doru -- www.tudorgirba.com "Every thing has its own flow"
I don't know anything about event handling, but I once had a look at Character constants, and found this: Character class>>#home ^ self value: 1 How about that ?? This is wrong IMHO, ASCII / Unicode value 1 is SOH (Start of header), sometimes typed as CTRL-A. And there are other strange constants like that there. On 25 Jun 2014, at 08:42, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I am on Windows, using Pharo 3.0, and I am trying to get the keybindings to work in Rubric using Windows convention (so, Ctrl instead of Cmd as a modifier),
It worked reasonably well, but the problem is that somehow Ctrl+a is mapped to Ctrl+Home. The problem is not specific to Rubric as I can detect the same behavior in the regular PluggableTextMorph.
Does anyone have an idea of where the problem comes from?
Doru
-- www.tudorgirba.com
"Every thing has its own flow"
There is a problem in the whole keyboard events: they treat keys as characters and vice versa. And that's not always true: - the backspace key is a key, but currently the image interprets it as a character because we only use keypress events in general. - the shift key is a key, and since current image does not use keyup nor keydown, we cannot know if JUST a shift is pressed normally. On Wed, Jun 25, 2014 at 8:53 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I don't know anything about event handling, but I once had a look at Character constants, and found this:
Character class>>#home ^ self value: 1
How about that ?? This is wrong IMHO, ASCII / Unicode value 1 is SOH (Start of header), sometimes typed as CTRL-A. And there are other strange constants like that there.
On 25 Jun 2014, at 08:42, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I am on Windows, using Pharo 3.0, and I am trying to get the keybindings to work in Rubric using Windows convention (so, Ctrl instead of Cmd as a modifier),
It worked reasonably well, but the problem is that somehow Ctrl+a is mapped to Ctrl+Home. The problem is not specific to Rubric as I can detect the same behavior in the regular PluggableTextMorph.
Does anyone have an idea of where the problem comes from?
Doru
-- www.tudorgirba.com
"Every thing has its own flow"
2014-06-25 8:58 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>:
There is a problem in the whole keyboard events: they treat keys as characters and vice versa. And that's not always true: - the backspace key is a key, but currently the image interprets it as a character because we only use keypress events in general. - the shift key is a key, and since current image does not use keyup nor keydown, we cannot know if JUST a shift is pressed normally.
On Wed, Jun 25, 2014 at 8:53 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I don't know anything about event handling, but I once had a look at Character constants, and found this:
Character class>>#home ^ self value: 1
How about that ?? This is wrong IMHO, ASCII / Unicode value 1 is SOH (Start of header), sometimes typed as CTRL-A. And there are other strange constants like that there.
On 25 Jun 2014, at 08:42, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I am on Windows, using Pharo 3.0, and I am trying to get the keybindings to work in Rubric using Windows convention (so, Ctrl instead of Cmd as a modifier),
It worked reasonably well, but the problem is that somehow Ctrl+a is mapped to Ctrl+Home. The problem is not specific to Rubric as I can detect the same behavior in the regular PluggableTextMorph.
Does anyone have an idea of where the problem comes from?
Doru
-- www.tudorgirba.com
"Every thing has its own flow"
ctrl+a has the same strange behavior as ctrl+d ctrl+a -> ctrl+home ctrl+d -> ctrl+end look at KeyboardEvent>>#hasSpecialCTRLKeyValue I am not exactly sure why it is handled that way. Replace the method with hasSpecialCTRLKeyValue ^ self controlKeyPressed and: [ keyValue <= 26 ] now, ctr+a and ctr+d working as expected. But I don't know about the side-effects. nicolai
I confirm that it fixes the symptom. I just cannot understand how it does so. Any idea? Doru On Wed, Jun 25, 2014 at 9:22 AM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-06-25 8:58 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>:
There is a problem in the whole keyboard events: they treat keys as
characters and vice versa. And that's not always true: - the backspace key is a key, but currently the image interprets it as a character because we only use keypress events in general. - the shift key is a key, and since current image does not use keyup nor keydown, we cannot know if JUST a shift is pressed normally.
On Wed, Jun 25, 2014 at 8:53 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I don't know anything about event handling, but I once had a look at Character constants, and found this:
Character class>>#home ^ self value: 1
How about that ?? This is wrong IMHO, ASCII / Unicode value 1 is SOH (Start of header), sometimes typed as CTRL-A. And there are other strange constants like that there.
On 25 Jun 2014, at 08:42, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I am on Windows, using Pharo 3.0, and I am trying to get the keybindings to work in Rubric using Windows convention (so, Ctrl instead of Cmd as a modifier),
It worked reasonably well, but the problem is that somehow Ctrl+a is mapped to Ctrl+Home. The problem is not specific to Rubric as I can detect the same behavior in the regular PluggableTextMorph.
Does anyone have an idea of where the problem comes from?
Doru
-- www.tudorgirba.com
"Every thing has its own flow"
ctrl+a has the same strange behavior as ctrl+d ctrl+a -> ctrl+home ctrl+d -> ctrl+end
look at KeyboardEvent>>#hasSpecialCTRLKeyValue I am not exactly sure why it is handled that way. Replace the method with
hasSpecialCTRLKeyValue ^ self controlKeyPressed and: [ keyValue <= 26 ]
now, ctr+a and ctr+d working as expected. But I don't know about the side-effects.
nicolai
-- www.tudorgirba.com "Every thing has its own flow"
Hi hasSpecialCTRLKeyValue was extracted by me when I hack keybindings to make ctrl+home and ctrl+end working. Like you I was very surprised by such keyboard events crappy state. 2014-06-25 11:22 GMT+04:00 Nicolai Hess <nicolaihess@web.de>:
2014-06-25 8:58 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>:
There is a problem in the whole keyboard events: they treat keys as
characters and vice versa. And that's not always true: - the backspace key is a key, but currently the image interprets it as a character because we only use keypress events in general. - the shift key is a key, and since current image does not use keyup nor keydown, we cannot know if JUST a shift is pressed normally.
On Wed, Jun 25, 2014 at 8:53 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I don't know anything about event handling, but I once had a look at Character constants, and found this:
Character class>>#home ^ self value: 1
How about that ?? This is wrong IMHO, ASCII / Unicode value 1 is SOH (Start of header), sometimes typed as CTRL-A. And there are other strange constants like that there.
On 25 Jun 2014, at 08:42, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I am on Windows, using Pharo 3.0, and I am trying to get the keybindings to work in Rubric using Windows convention (so, Ctrl instead of Cmd as a modifier),
It worked reasonably well, but the problem is that somehow Ctrl+a is mapped to Ctrl+Home. The problem is not specific to Rubric as I can detect the same behavior in the regular PluggableTextMorph.
Does anyone have an idea of where the problem comes from?
Doru
-- www.tudorgirba.com
"Every thing has its own flow"
ctrl+a has the same strange behavior as ctrl+d ctrl+a -> ctrl+home ctrl+d -> ctrl+end
look at KeyboardEvent>>#hasSpecialCTRLKeyValue I am not exactly sure why it is handled that way. Replace the method with
hasSpecialCTRLKeyValue ^ self controlKeyPressed and: [ keyValue <= 26 ]
now, ctr+a and ctr+d working as expected. But I don't know about the side-effects.
nicolai
2014-06-29 16:34 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
Hi
hasSpecialCTRLKeyValue was extracted by me when I hack keybindings to make ctrl+home and ctrl+end working. Like you I was very surprised by such keyboard events crappy state.
So, having ctrl+end and ctrl+d working at the same time is not possible?
2014-06-25 11:22 GMT+04:00 Nicolai Hess <nicolaihess@web.de>:
2014-06-25 8:58 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>:
There is a problem in the whole keyboard events: they treat keys as
characters and vice versa. And that's not always true: - the backspace key is a key, but currently the image interprets it as a character because we only use keypress events in general. - the shift key is a key, and since current image does not use keyup nor keydown, we cannot know if JUST a shift is pressed normally.
On Wed, Jun 25, 2014 at 8:53 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I don't know anything about event handling, but I once had a look at Character constants, and found this:
Character class>>#home ^ self value: 1
How about that ?? This is wrong IMHO, ASCII / Unicode value 1 is SOH (Start of header), sometimes typed as CTRL-A. And there are other strange constants like that there.
On 25 Jun 2014, at 08:42, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I am on Windows, using Pharo 3.0, and I am trying to get the keybindings to work in Rubric using Windows convention (so, Ctrl instead of Cmd as a modifier),
It worked reasonably well, but the problem is that somehow Ctrl+a is mapped to Ctrl+Home. The problem is not specific to Rubric as I can detect the same behavior in the regular PluggableTextMorph.
Does anyone have an idea of where the problem comes from?
Doru
-- www.tudorgirba.com
"Every thing has its own flow"
ctrl+a has the same strange behavior as ctrl+d ctrl+a -> ctrl+home ctrl+d -> ctrl+end
look at KeyboardEvent>>#hasSpecialCTRLKeyValue I am not exactly sure why it is handled that way. Replace the method with
hasSpecialCTRLKeyValue ^ self controlKeyPressed and: [ keyValue <= 26 ]
now, ctr+a and ctr+d working as expected. But I don't know about the side-effects.
nicolai
There is an end key in many keyboards, but some others do not have it. Can you (or better, How would you) have ctrl+end in keyboards that doesn't? Some VMs hardcoded that Ctrl+a = ctrl+home and Ctrl+d = Ctrl+end because that's how old terminals work... Now, why have hardcoded ctrl+a = ctrl + home, if you can just add a keybinding to ctrl + a? On Mon, Jun 30, 2014 at 8:55 AM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-06-29 16:34 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
Hi
hasSpecialCTRLKeyValue was extracted by me when I hack keybindings to make ctrl+home and ctrl+end working. Like you I was very surprised by such keyboard events crappy state.
So, having ctrl+end and ctrl+d working at the same time is not possible?
2014-06-25 11:22 GMT+04:00 Nicolai Hess <nicolaihess@web.de>:
2014-06-25 8:58 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>:
There is a problem in the whole keyboard events: they treat keys as
characters and vice versa. And that's not always true: - the backspace key is a key, but currently the image interprets it as a character because we only use keypress events in general. - the shift key is a key, and since current image does not use keyup nor keydown, we cannot know if JUST a shift is pressed normally.
On Wed, Jun 25, 2014 at 8:53 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I don't know anything about event handling, but I once had a look at Character constants, and found this:
Character class>>#home ^ self value: 1
How about that ?? This is wrong IMHO, ASCII / Unicode value 1 is SOH (Start of header), sometimes typed as CTRL-A. And there are other strange constants like that there.
On 25 Jun 2014, at 08:42, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I am on Windows, using Pharo 3.0, and I am trying to get the keybindings to work in Rubric using Windows convention (so, Ctrl instead of Cmd as a modifier),
It worked reasonably well, but the problem is that somehow Ctrl+a is mapped to Ctrl+Home. The problem is not specific to Rubric as I can detect the same behavior in the regular PluggableTextMorph.
Does anyone have an idea of where the problem comes from?
Doru
-- www.tudorgirba.com
"Every thing has its own flow"
ctrl+a has the same strange behavior as ctrl+d ctrl+a -> ctrl+home ctrl+d -> ctrl+end
look at KeyboardEvent>>#hasSpecialCTRLKeyValue I am not exactly sure why it is handled that way. Replace the method with
hasSpecialCTRLKeyValue ^ self controlKeyPressed and: [ keyValue <= 26 ]
now, ctr+a and ctr+d working as expected. But I don't know about the side-effects.
nicolai
I added an issue: 15541 <https://pharo.fogbugz.com/default.asp?15541> windows vm does not distinguish between ctrl+a and ctrl+home with a proposed solution: add $a-1 to the utf32Code field of the event struct, if the keyevent is a keystroke and the ctrl flag is set what do you think? 2014-06-30 9:31 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>:
There is an end key in many keyboards, but some others do not have it. Can you (or better, How would you) have ctrl+end in keyboards that doesn't?
Some VMs hardcoded that Ctrl+a = ctrl+home and Ctrl+d = Ctrl+end because that's how old terminals work... Now, why have hardcoded ctrl+a = ctrl + home, if you can just add a keybinding to ctrl + a?
On Mon, Jun 30, 2014 at 8:55 AM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-06-29 16:34 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
Hi
hasSpecialCTRLKeyValue was extracted by me when I hack keybindings to make ctrl+home and ctrl+end working. Like you I was very surprised by such keyboard events crappy state.
So, having ctrl+end and ctrl+d working at the same time is not possible?
2014-06-25 11:22 GMT+04:00 Nicolai Hess <nicolaihess@web.de>:
2014-06-25 8:58 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>:
There is a problem in the whole keyboard events: they treat keys as
characters and vice versa. And that's not always true: - the backspace key is a key, but currently the image interprets it as a character because we only use keypress events in general. - the shift key is a key, and since current image does not use keyup nor keydown, we cannot know if JUST a shift is pressed normally.
On Wed, Jun 25, 2014 at 8:53 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I don't know anything about event handling, but I once had a look at Character constants, and found this:
Character class>>#home ^ self value: 1
How about that ?? This is wrong IMHO, ASCII / Unicode value 1 is SOH (Start of header), sometimes typed as CTRL-A. And there are other strange constants like that there.
On 25 Jun 2014, at 08:42, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I am on Windows, using Pharo 3.0, and I am trying to get the keybindings to work in Rubric using Windows convention (so, Ctrl instead of Cmd as a modifier),
It worked reasonably well, but the problem is that somehow Ctrl+a is mapped to Ctrl+Home. The problem is not specific to Rubric as I can detect the same behavior in the regular PluggableTextMorph.
Does anyone have an idea of where the problem comes from?
Doru
-- www.tudorgirba.com
"Every thing has its own flow"
ctrl+a has the same strange behavior as ctrl+d ctrl+a -> ctrl+home ctrl+d -> ctrl+end
look at KeyboardEvent>>#hasSpecialCTRLKeyValue I am not exactly sure why it is handled that way. Replace the method with
hasSpecialCTRLKeyValue ^ self controlKeyPressed and: [ keyValue <= 26 ]
now, ctr+a and ctr+d working as expected. But I don't know about the side-effects.
nicolai
forward to vm-dev 2015-05-14 21:34 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:
I added an issue:
15541 <https://pharo.fogbugz.com/default.asp?15541> windows vm does not distinguish between ctrl+a and ctrl+home
with a proposed solution: add $a-1 to the utf32Code field of the event struct, if the keyevent is a keystroke and the ctrl flag is set
what do you think?
this happens on squeak (vm: Win32 built on Aug 22 2013 10:20:54 Compiler: 3.4.4 ) too. But the eventbuffer is different: pharo ctrl+a/ctrl+home both report: #(2 TIMESTAMP 1 0 2 1 0 1) squeak ctrl+a/ctrl+home both report: #(2 TIMESTAMP 1 0 8 97 0 1)
2014-06-30 9:31 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>:
There is an end key in many keyboards, but some others do not have it. Can you (or better, How would you) have ctrl+end in keyboards that doesn't?
Some VMs hardcoded that Ctrl+a = ctrl+home and Ctrl+d = Ctrl+end because that's how old terminals work... Now, why have hardcoded ctrl+a = ctrl + home, if you can just add a keybinding to ctrl + a?
On Mon, Jun 30, 2014 at 8:55 AM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-06-29 16:34 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
Hi
hasSpecialCTRLKeyValue was extracted by me when I hack keybindings to make ctrl+home and ctrl+end working. Like you I was very surprised by such keyboard events crappy state.
So, having ctrl+end and ctrl+d working at the same time is not possible?
2014-06-25 11:22 GMT+04:00 Nicolai Hess <nicolaihess@web.de>:
2014-06-25 8:58 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>:
There is a problem in the whole keyboard events: they treat keys as
characters and vice versa. And that's not always true: - the backspace key is a key, but currently the image interprets it as a character because we only use keypress events in general. - the shift key is a key, and since current image does not use keyup nor keydown, we cannot know if JUST a shift is pressed normally.
On Wed, Jun 25, 2014 at 8:53 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I don't know anything about event handling, but I once had a look at Character constants, and found this:
Character class>>#home ^ self value: 1
How about that ?? This is wrong IMHO, ASCII / Unicode value 1 is SOH (Start of header), sometimes typed as CTRL-A. And there are other strange constants like that there.
On 25 Jun 2014, at 08:42, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I am on Windows, using Pharo 3.0, and I am trying to get the keybindings to work in Rubric using Windows convention (so, Ctrl instead of Cmd as a modifier),
It worked reasonably well, but the problem is that somehow Ctrl+a is mapped to Ctrl+Home. The problem is not specific to Rubric as I can detect the same behavior in the regular PluggableTextMorph.
Does anyone have an idea of where the problem comes from?
Doru
-- www.tudorgirba.com
"Every thing has its own flow"
ctrl+a has the same strange behavior as ctrl+d ctrl+a -> ctrl+home ctrl+d -> ctrl+end
look at KeyboardEvent>>#hasSpecialCTRLKeyValue I am not exactly sure why it is handled that way. Replace the method with
hasSpecialCTRLKeyValue ^ self controlKeyPressed and: [ keyValue <= 26 ]
now, ctr+a and ctr+d working as expected. But I don't know about the side-effects.
nicolai
2015-05-15 8:40 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:
forward to vm-dev
2015-05-14 21:34 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:
I added an issue:
15541 <https://pharo.fogbugz.com/default.asp?15541> windows vm does not distinguish between ctrl+a and ctrl+home
with a proposed solution: add $a-1 to the utf32Code field of the event struct, if the keyevent is a keystroke and the ctrl flag is set
what do you think?
this happens on squeak (vm: Win32 built on Aug 22 2013 10:20:54 Compiler: 3.4.4 ) too. But the eventbuffer is different: pharo ctrl+a/ctrl+home both report:
#(2 TIMESTAMP 1 0 2 1 0 1)
squeak ctrl+a/ctrl+home both report: #(2 TIMESTAMP 1 0 8 97 0 1)
if you have a vm build environment for windows, you can test my proposed solution: https://github.com/pharo-project/pharo-vm/pull/75 15541 <https://pharo.fogbugz.com/default.asp?15541> windows vm does not distinguish between ctrl+a and ctrl+home
2014-06-30 9:31 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>:
There is an end key in many keyboards, but some others do not have it. Can you (or better, How would you) have ctrl+end in keyboards that doesn't?
Some VMs hardcoded that Ctrl+a = ctrl+home and Ctrl+d = Ctrl+end because that's how old terminals work... Now, why have hardcoded ctrl+a = ctrl + home, if you can just add a keybinding to ctrl + a?
On Mon, Jun 30, 2014 at 8:55 AM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-06-29 16:34 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
Hi
hasSpecialCTRLKeyValue was extracted by me when I hack keybindings to make ctrl+home and ctrl+end working. Like you I was very surprised by such keyboard events crappy state.
So, having ctrl+end and ctrl+d working at the same time is not possible?
2014-06-25 11:22 GMT+04:00 Nicolai Hess <nicolaihess@web.de>:
2014-06-25 8:58 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>
:
There is a problem in the whole keyboard events: they treat keys as
characters and vice versa. And that's not always true: - the backspace key is a key, but currently the image interprets it as a character because we only use keypress events in general. - the shift key is a key, and since current image does not use keyup nor keydown, we cannot know if JUST a shift is pressed normally.
On Wed, Jun 25, 2014 at 8:53 AM, Sven Van Caekenberghe <sven@stfx.eu
wrote:
I don't know anything about event handling, but I once had a look at Character constants, and found this:
Character class>>#home ^ self value: 1
How about that ?? This is wrong IMHO, ASCII / Unicode value 1 is SOH (Start of header), sometimes typed as CTRL-A. And there are other strange constants like that there.
On 25 Jun 2014, at 08:42, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I am on Windows, using Pharo 3.0, and I am trying to get the keybindings to work in Rubric using Windows convention (so, Ctrl instead of Cmd as a modifier),
It worked reasonably well, but the problem is that somehow Ctrl+a is mapped to Ctrl+Home. The problem is not specific to Rubric as I can detect the same behavior in the regular PluggableTextMorph.
Does anyone have an idea of where the problem comes from?
Doru
-- www.tudorgirba.com
"Every thing has its own flow"
ctrl+a has the same strange behavior as ctrl+d ctrl+a -> ctrl+home ctrl+d -> ctrl+end
look at KeyboardEvent>>#hasSpecialCTRLKeyValue I am not exactly sure why it is handled that way. Replace the method with
hasSpecialCTRLKeyValue ^ self controlKeyPressed and: [ keyValue <= 26 ]
now, ctr+a and ctr+d working as expected. But I don't know about the side-effects.
nicolai
I think it is a VM problem (that does magic conversions :) ), but to actually know it you can log the output of the InputEventFetcher (so you know what you have before it enters into the morphic world). On Wed, Jun 25, 2014 at 8:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I am on Windows, using Pharo 3.0, and I am trying to get the keybindings to work in Rubric using Windows convention (so, Ctrl instead of Cmd as a modifier),
It worked reasonably well, but the problem is that somehow Ctrl+a is mapped to Ctrl+Home. The problem is not specific to Rubric as I can detect the same behavior in the regular PluggableTextMorph.
Does anyone have an idea of where the problem comes from?
Doru
-- www.tudorgirba.com
"Every thing has its own flow"
participants (5)
-
Denis Kudriashov -
Guillermo Polito -
Nicolai Hess -
Sven Van Caekenberghe -
Tudor Girba