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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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-25 8:58 GMT+02:00 Guillermo Polito <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]>:

2014-06-25 8:58 GMT+02:00 Guillermo Polito <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

2014-06-29 16:34 GMT+02:00 Denis Kudriashov <[hidden email]>:

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 <[hidden email]>:

2014-06-25 8:58 GMT+02:00 Guillermo Polito <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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