[BUG] Keyhandling on Windows

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[BUG] Keyhandling on Windows

Christoph Thiede

Hi all,


sorry to report to you another, though minor issue related to keyboard handling.


Steps to reproduce:

  • Open a fresh trunk image on Windows
  • turn off num lock (so that 4 works like arrowLeft)
  • Go to any editor, such as workspace
  • Press the number key 5

Expected behavior:
No character is inserted, as digits are turned off.

Actual behavior:
The quotes character (") is inserted.

Notes:
The issue already existed in Squeak 5.2, 4.6 and 3.9 (from my random tests).

Best,
Christoph



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: [BUG] Keyhandling on Windows

Christoph Thiede

Possibly related issue:

Ctrl + End generates an event like this: keystroke '<Cmd-d>' (100)


Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Freitag, 21. Februar 2020 14:22:18
An: Squeak Dev
Betreff: [squeak-dev] [BUG] Keyhandling on Windows
 

Hi all,


sorry to report to you another, though minor issue related to keyboard handling.


Steps to reproduce:

  • Open a fresh trunk image on Windows
  • turn off num lock (so that 4 works like arrowLeft)
  • Go to any editor, such as workspace
  • Press the number key 5

Expected behavior:
No character is inserted, as digits are turned off.

Actual behavior:
The quotes character (") is inserted.

Notes:
The issue already existed in Squeak 5.2, 4.6 and 3.9 (from my random tests).

Best,
Christoph



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: [BUG] Keyhandling on Windows

Christoph Thiede

Ctrl + Home - keystroke '<Cmd-a>' (97)

Ctrl + End - keystroke '<Cmd-d>' (100)

Ctrl + Insert - keystroke '<Cmd-e>'

Ctrl + PageUp - keystroke '<Cmd-k>'
Ctrl + PageDown - keystroke '<Cmd-l>' (108)
Only Ctrl + Delete works ...

Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Freitag, 28. Februar 2020 19:20:30
An: Squeak Dev
Betreff: Re: [squeak-dev] [BUG] Keyhandling on Windows
 

Possibly related issue:

Ctrl + End generates an event like this: keystroke '<Cmd-d>' (100)


Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Freitag, 21. Februar 2020 14:22:18
An: Squeak Dev
Betreff: [squeak-dev] [BUG] Keyhandling on Windows
 

Hi all,


sorry to report to you another, though minor issue related to keyboard handling.


Steps to reproduce:

  • Open a fresh trunk image on Windows
  • turn off num lock (so that 4 works like arrowLeft)
  • Go to any editor, such as workspace
  • Press the number key 5

Expected behavior:
No character is inserted, as digits are turned off.

Actual behavior:
The quotes character (") is inserted.

Notes:
The issue already existed in Squeak 5.2, 4.6 and 3.9 (from my random tests).

Best,
Christoph



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: [BUG] Keyhandling on Windows

marcel.taeumel
Hi Christoph.

Try looking on squeak-dev for more information about user-input event processing and their quirks on various platforms.

In this case, it would help if you could find out the raw event data that arrives in Squeak through the EventSensor. It is an array filled with numbers. That a look at the class comment from EventSensor.

Considering control keys, also take a look at the mapping tables in TextEditor and all its subclasses.

We chose to not touch this issue in 5.3. We might want to harmonize that after the release.

I am in favor of programming against "#isControlKeyPressed and #keyCharacter ==" instead of actual control keycodes: 

https://en.wikipedia.org/wiki/Control_character
http://www.physics.udel.edu/~watson/scen103/ascii.html

It would feel more object-oriented. But that's just my two cents. ;-) I rarely work in terminals. Anyway, one could easily map all control keycodes to higher-level object events in EventSensor or HandMorph.

Or maybe use [cmd]+[c] instead of [ctrl]+[c] anyway ... Hmmm....

Best,
Marcel

Am 28.02.2020 19:24:27 schrieb Thiede, Christoph <[hidden email]>:

Ctrl + Home - keystroke '<Cmd-a>' (97)

Ctrl + End - keystroke '<Cmd-d>' (100)

Ctrl + Insert - keystroke '<Cmd-e>'

Ctrl + PageUp - keystroke '<Cmd-k>'
Ctrl + PageDown - keystroke '<Cmd-l>' (108)
Only Ctrl + Delete works ...

Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Freitag, 28. Februar 2020 19:20:30
An: Squeak Dev
Betreff: Re: [squeak-dev] [BUG] Keyhandling on Windows
 

Possibly related issue:

Ctrl + End generates an event like this: keystroke '<Cmd-d>' (100)


Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Freitag, 21. Februar 2020 14:22:18
An: Squeak Dev
Betreff: [squeak-dev] [BUG] Keyhandling on Windows
 

Hi all,


sorry to report to you another, though minor issue related to keyboard handling.


Steps to reproduce:

  • Open a fresh trunk image on Windows
  • turn off num lock (so that 4 works like arrowLeft)
  • Go to any editor, such as workspace
  • Press the number key 5

Expected behavior:
No character is inserted, as digits are turned off.

Actual behavior:
The quotes character (") is inserted.

Notes:
The issue already existed in Squeak 5.2, 4.6 and 3.9 (from my random tests).

Best,
Christoph



Reply | Threaded
Open this post in threaded view
|

Re: [BUG] Keyhandling on Windows

Christoph Thiede

Hi Marcel,


thanks, maybe I will take a closer look at it :-)


So long, treat this as a note to myself:


Ctrl + Enter is also broken. It produces keystroke '<Cmd-j>' (106).


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 2. März 2020 10:50:28
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] [BUG] Keyhandling on Windows
 
Hi Christoph.

Try looking on squeak-dev for more information about user-input event processing and their quirks on various platforms.

In this case, it would help if you could find out the raw event data that arrives in Squeak through the EventSensor. It is an array filled with numbers. That a look at the class comment from EventSensor.

Considering control keys, also take a look at the mapping tables in TextEditor and all its subclasses.

We chose to not touch this issue in 5.3. We might want to harmonize that after the release.

I am in favor of programming against "#isControlKeyPressed and #keyCharacter ==" instead of actual control keycodes: 

https://en.wikipedia.org/wiki/Control_character
http://www.physics.udel.edu/~watson/scen103/ascii.html

It would feel more object-oriented. But that's just my two cents. ;-) I rarely work in terminals. Anyway, one could easily map all control keycodes to higher-level object events in EventSensor or HandMorph.

Or maybe use [cmd]+[c] instead of [ctrl]+[c] anyway ... Hmmm....

Best,
Marcel

Am 28.02.2020 19:24:27 schrieb Thiede, Christoph <[hidden email]>:

Ctrl + Home - keystroke '<Cmd-a>' (97)

Ctrl + End - keystroke '<Cmd-d>' (100)

Ctrl + Insert - keystroke '<Cmd-e>'

Ctrl + PageUp - keystroke '<Cmd-k>'
Ctrl + PageDown - keystroke '<Cmd-l>' (108)
Only Ctrl + Delete works ...

Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Freitag, 28. Februar 2020 19:20:30
An: Squeak Dev
Betreff: Re: [squeak-dev] [BUG] Keyhandling on Windows
 

Possibly related issue:

Ctrl + End generates an event like this: keystroke '<Cmd-d>' (100)


Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Freitag, 21. Februar 2020 14:22:18
An: Squeak Dev
Betreff: [squeak-dev] [BUG] Keyhandling on Windows
 

Hi all,


sorry to report to you another, though minor issue related to keyboard handling.


Steps to reproduce:

  • Open a fresh trunk image on Windows
  • turn off num lock (so that 4 works like arrowLeft)
  • Go to any editor, such as workspace
  • Press the number key 5

Expected behavior:
No character is inserted, as digits are turned off.

Actual behavior:
The quotes character (") is inserted.

Notes:
The issue already existed in Squeak 5.2, 4.6 and 3.9 (from my random tests).

Best,
Christoph



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: [BUG] Keyhandling on Windows

marcel.taeumel
Ctrl + Enter is also broken. It produces keystroke '<Cmd-j>' (106).

Do you mean [enter] or [return]? ;-) "line feed" is actually CTRL-J, which is ASCII 10. If you do not happen do have the actual LF key on your keyboard, which is [enter].


If you "duplicate all control/alt keys", that input will be translated to an actual [j] (ASCII 106) in the EventSensor.

This can be quite confusing. I would like to agree on a common programming model for keyboard events in Squeak. Too much platform-specific, low-level stuff leaks into the image. Even inconsistently on the same platform.

Best,
Marcel

Am 02.03.2020 19:37:16 schrieb Thiede, Christoph <[hidden email]>:

Hi Marcel,


thanks, maybe I will take a closer look at it :-)


So long, treat this as a note to myself:


Ctrl + Enter is also broken. It produces keystroke '<Cmd-j>' (106).


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 2. März 2020 10:50:28
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] [BUG] Keyhandling on Windows
 
Hi Christoph.

Try looking on squeak-dev for more information about user-input event processing and their quirks on various platforms.

In this case, it would help if you could find out the raw event data that arrives in Squeak through the EventSensor. It is an array filled with numbers. That a look at the class comment from EventSensor.

Considering control keys, also take a look at the mapping tables in TextEditor and all its subclasses.

We chose to not touch this issue in 5.3. We might want to harmonize that after the release.

I am in favor of programming against "#isControlKeyPressed and #keyCharacter ==" instead of actual control keycodes: 

https://en.wikipedia.org/wiki/Control_character
http://www.physics.udel.edu/~watson/scen103/ascii.html

It would feel more object-oriented. But that's just my two cents. ;-) I rarely work in terminals. Anyway, one could easily map all control keycodes to higher-level object events in EventSensor or HandMorph.

Or maybe use [cmd]+[c] instead of [ctrl]+[c] anyway ... Hmmm....

Best,
Marcel

Am 28.02.2020 19:24:27 schrieb Thiede, Christoph <[hidden email]>:

Ctrl + Home - keystroke '<Cmd-a>' (97)

Ctrl + End - keystroke '<Cmd-d>' (100)

Ctrl + Insert - keystroke '<Cmd-e>'

Ctrl + PageUp - keystroke '<Cmd-k>'
Ctrl + PageDown - keystroke '<Cmd-l>' (108)
Only Ctrl + Delete works ...

Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Freitag, 28. Februar 2020 19:20:30
An: Squeak Dev
Betreff: Re: [squeak-dev] [BUG] Keyhandling on Windows
 

Possibly related issue:

Ctrl + End generates an event like this: keystroke '<Cmd-d>' (100)


Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Freitag, 21. Februar 2020 14:22:18
An: Squeak Dev
Betreff: [squeak-dev] [BUG] Keyhandling on Windows
 

Hi all,


sorry to report to you another, though minor issue related to keyboard handling.


Steps to reproduce:

  • Open a fresh trunk image on Windows
  • turn off num lock (so that 4 works like arrowLeft)
  • Go to any editor, such as workspace
  • Press the number key 5

Expected behavior:
No character is inserted, as digits are turned off.

Actual behavior:
The quotes character (") is inserted.

Notes:
The issue already existed in Squeak 5.2, 4.6 and 3.9 (from my random tests).

Best,
Christoph



Reply | Threaded
Open this post in threaded view
|

Re: [BUG] Keyhandling on Windows

Christoph Thiede

I mean Enter.


:-)


This is indeed confusing. Pressing Enter in an editor inserts a carriage return character rather than a line feed character. But pressing Ctrl + Enter is understood as <Cmd-j>. Never heard of this ascii mapping before. I don't see how this would be useful if you use a modern keyboard? I want a preference that makes my keyboard "work the same as in Windows" ;-)


This can be quite confusing. I would like to agree on a common programming model for keyboard events in Squeak. Too much platform-specific, low-level stuff leaks into the image. Even inconsistently on the same platform.


This would be definitively useful!

Best,
Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 3. März 2020 08:46:18
An: Robert via Squeak-dev
Betreff: Re: [squeak-dev] [BUG] Keyhandling on Windows
 
Ctrl + Enter is also broken. It produces keystroke '<Cmd-j>' (106).

Do you mean [enter] or [return]? ;-) "line feed" is actually CTRL-J, which is ASCII 10. If you do not happen do have the actual LF key on your keyboard, which is [enter].


If you "duplicate all control/alt keys", that input will be translated to an actual [j] (ASCII 106) in the EventSensor.

This can be quite confusing. I would like to agree on a common programming model for keyboard events in Squeak. Too much platform-specific, low-level stuff leaks into the image. Even inconsistently on the same platform.

Best,
Marcel

Am 02.03.2020 19:37:16 schrieb Thiede, Christoph <[hidden email]>:

Hi Marcel,


thanks, maybe I will take a closer look at it :-)


So long, treat this as a note to myself:


Ctrl + Enter is also broken. It produces keystroke '<Cmd-j>' (106).


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 2. März 2020 10:50:28
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] [BUG] Keyhandling on Windows
 
Hi Christoph.

Try looking on squeak-dev for more information about user-input event processing and their quirks on various platforms.

In this case, it would help if you could find out the raw event data that arrives in Squeak through the EventSensor. It is an array filled with numbers. That a look at the class comment from EventSensor.

Considering control keys, also take a look at the mapping tables in TextEditor and all its subclasses.

We chose to not touch this issue in 5.3. We might want to harmonize that after the release.

I am in favor of programming against "#isControlKeyPressed and #keyCharacter ==" instead of actual control keycodes: 

https://en.wikipedia.org/wiki/Control_character
http://www.physics.udel.edu/~watson/scen103/ascii.html

It would feel more object-oriented. But that's just my two cents. ;-) I rarely work in terminals. Anyway, one could easily map all control keycodes to higher-level object events in EventSensor or HandMorph.

Or maybe use [cmd]+[c] instead of [ctrl]+[c] anyway ... Hmmm....

Best,
Marcel

Am 28.02.2020 19:24:27 schrieb Thiede, Christoph <[hidden email]>:

Ctrl + Home - keystroke '<Cmd-a>' (97)

Ctrl + End - keystroke '<Cmd-d>' (100)

Ctrl + Insert - keystroke '<Cmd-e>'

Ctrl + PageUp - keystroke '<Cmd-k>'
Ctrl + PageDown - keystroke '<Cmd-l>' (108)
Only Ctrl + Delete works ...

Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Freitag, 28. Februar 2020 19:20:30
An: Squeak Dev
Betreff: Re: [squeak-dev] [BUG] Keyhandling on Windows
 

Possibly related issue:

Ctrl + End generates an event like this: keystroke '<Cmd-d>' (100)


Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Freitag, 21. Februar 2020 14:22:18
An: Squeak Dev
Betreff: [squeak-dev] [BUG] Keyhandling on Windows
 

Hi all,


sorry to report to you another, though minor issue related to keyboard handling.


Steps to reproduce:

  • Open a fresh trunk image on Windows
  • turn off num lock (so that 4 works like arrowLeft)
  • Go to any editor, such as workspace
  • Press the number key 5

Expected behavior:
No character is inserted, as digits are turned off.

Actual behavior:
The quotes character (") is inserted.

Notes:
The issue already existed in Squeak 5.2, 4.6 and 3.9 (from my random tests).

Best,
Christoph



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: [BUG] Keyhandling on Windows

marcel.taeumel
Pressing Enter in an editor inserts a carriage return character rather than a line feed character.

Then your keyboard is mislabeled. Pressing [return] inserts a CR, pressing [enter] inserts an LF. However, there might be design reason for keyboard vendors to do otherwise, I suppose.

So you do mean [return]. ;-)

Or do you have that numeric keypad overlayed in a way that enabled the [return] key to be [enter] and vice versa?

Best,
Marcel

Am 03.03.2020 09:06:25 schrieb Thiede, Christoph <[hidden email]>:

I mean Enter.


:-)


This is indeed confusing. Pressing Enter in an editor inserts a carriage return character rather than a line feed character. But pressing Ctrl + Enter is understood as <Cmd-j>. Never heard of this ascii mapping before. I don't see how this would be useful if you use a modern keyboard? I want a preference that makes my keyboard "work the same as in Windows" ;-)


This can be quite confusing. I would like to agree on a common programming model for keyboard events in Squeak. Too much platform-specific, low-level stuff leaks into the image. Even inconsistently on the same platform.


This would be definitively useful!

Best,
Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 3. März 2020 08:46:18
An: Robert via Squeak-dev
Betreff: Re: [squeak-dev] [BUG] Keyhandling on Windows
 
Ctrl + Enter is also broken. It produces keystroke '<Cmd-j>' (106).

Do you mean [enter] or [return]? ;-) "line feed" is actually CTRL-J, which is ASCII 10. If you do not happen do have the actual LF key on your keyboard, which is [enter].


If you "duplicate all control/alt keys", that input will be translated to an actual [j] (ASCII 106) in the EventSensor.

This can be quite confusing. I would like to agree on a common programming model for keyboard events in Squeak. Too much platform-specific, low-level stuff leaks into the image. Even inconsistently on the same platform.

Best,
Marcel

Am 02.03.2020 19:37:16 schrieb Thiede, Christoph <[hidden email]>:

Hi Marcel,


thanks, maybe I will take a closer look at it :-)


So long, treat this as a note to myself:


Ctrl + Enter is also broken. It produces keystroke '<Cmd-j>' (106).


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 2. März 2020 10:50:28
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] [BUG] Keyhandling on Windows
 
Hi Christoph.

Try looking on squeak-dev for more information about user-input event processing and their quirks on various platforms.

In this case, it would help if you could find out the raw event data that arrives in Squeak through the EventSensor. It is an array filled with numbers. That a look at the class comment from EventSensor.

Considering control keys, also take a look at the mapping tables in TextEditor and all its subclasses.

We chose to not touch this issue in 5.3. We might want to harmonize that after the release.

I am in favor of programming against "#isControlKeyPressed and #keyCharacter ==" instead of actual control keycodes: 

https://en.wikipedia.org/wiki/Control_character
http://www.physics.udel.edu/~watson/scen103/ascii.html

It would feel more object-oriented. But that's just my two cents. ;-) I rarely work in terminals. Anyway, one could easily map all control keycodes to higher-level object events in EventSensor or HandMorph.

Or maybe use [cmd]+[c] instead of [ctrl]+[c] anyway ... Hmmm....

Best,
Marcel

Am 28.02.2020 19:24:27 schrieb Thiede, Christoph <[hidden email]>:

Ctrl + Home - keystroke '<Cmd-a>' (97)

Ctrl + End - keystroke '<Cmd-d>' (100)

Ctrl + Insert - keystroke '<Cmd-e>'

Ctrl + PageUp - keystroke '<Cmd-k>'
Ctrl + PageDown - keystroke '<Cmd-l>' (108)
Only Ctrl + Delete works ...

Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Freitag, 28. Februar 2020 19:20:30
An: Squeak Dev
Betreff: Re: [squeak-dev] [BUG] Keyhandling on Windows
 

Possibly related issue:

Ctrl + End generates an event like this: keystroke '<Cmd-d>' (100)


Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Freitag, 21. Februar 2020 14:22:18
An: Squeak Dev
Betreff: [squeak-dev] [BUG] Keyhandling on Windows
 

Hi all,


sorry to report to you another, though minor issue related to keyboard handling.


Steps to reproduce:

  • Open a fresh trunk image on Windows
  • turn off num lock (so that 4 works like arrowLeft)
  • Go to any editor, such as workspace
  • Press the number key 5

Expected behavior:
No character is inserted, as digits are turned off.

Actual behavior:
The quotes character (") is inserted.

Notes:
The issue already existed in Squeak 5.2, 4.6 and 3.9 (from my random tests).

Best,
Christoph



Reply | Threaded
Open this post in threaded view
|

Re: [BUG] Keyhandling on Windows

Chris Muller-3
Enter and Return are the same key on US keyboards.  They show the return-arrow graphic AND the word "Enter" printed on them.

I've never known them to be different keys..



On Tue, Mar 3, 2020 at 2:44 AM Marcel Taeumel <[hidden email]> wrote:
Pressing Enter in an editor inserts a carriage return character rather than a line feed character.

Then your keyboard is mislabeled. Pressing [return] inserts a CR, pressing [enter] inserts an LF. However, there might be design reason for keyboard vendors to do otherwise, I suppose.

So you do mean [return]. ;-)

Or do you have that numeric keypad overlayed in a way that enabled the [return] key to be [enter] and vice versa?

Best,
Marcel

Am 03.03.2020 09:06:25 schrieb Thiede, Christoph <[hidden email]>:

I mean Enter.


:-)


This is indeed confusing. Pressing Enter in an editor inserts a carriage return character rather than a line feed character. But pressing Ctrl + Enter is understood as <Cmd-j>. Never heard of this ascii mapping before. I don't see how this would be useful if you use a modern keyboard? I want a preference that makes my keyboard "work the same as in Windows" ;-)


This can be quite confusing. I would like to agree on a common programming model for keyboard events in Squeak. Too much platform-specific, low-level stuff leaks into the image. Even inconsistently on the same platform.


This would be definitively useful!

Best,
Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 3. März 2020 08:46:18
An: Robert via Squeak-dev
Betreff: Re: [squeak-dev] [BUG] Keyhandling on Windows
 
Ctrl + Enter is also broken. It produces keystroke '<Cmd-j>' (106).

Do you mean [enter] or [return]? ;-) "line feed" is actually CTRL-J, which is ASCII 10. If you do not happen do have the actual LF key on your keyboard, which is [enter].


If you "duplicate all control/alt keys", that input will be translated to an actual [j] (ASCII 106) in the EventSensor.

This can be quite confusing. I would like to agree on a common programming model for keyboard events in Squeak. Too much platform-specific, low-level stuff leaks into the image. Even inconsistently on the same platform.

Best,
Marcel

Am 02.03.2020 19:37:16 schrieb Thiede, Christoph <[hidden email]>:

Hi Marcel,


thanks, maybe I will take a closer look at it :-)


So long, treat this as a note to myself:


Ctrl + Enter is also broken. It produces keystroke '<Cmd-j>' (106).


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 2. März 2020 10:50:28
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] [BUG] Keyhandling on Windows
 
Hi Christoph.

Try looking on squeak-dev for more information about user-input event processing and their quirks on various platforms.

In this case, it would help if you could find out the raw event data that arrives in Squeak through the EventSensor. It is an array filled with numbers. That a look at the class comment from EventSensor.

Considering control keys, also take a look at the mapping tables in TextEditor and all its subclasses.

We chose to not touch this issue in 5.3. We might want to harmonize that after the release.

I am in favor of programming against "#isControlKeyPressed and #keyCharacter ==" instead of actual control keycodes: 


It would feel more object-oriented. But that's just my two cents. ;-) I rarely work in terminals. Anyway, one could easily map all control keycodes to higher-level object events in EventSensor or HandMorph.

Or maybe use [cmd]+[c] instead of [ctrl]+[c] anyway ... Hmmm....

Best,
Marcel

Am 28.02.2020 19:24:27 schrieb Thiede, Christoph <[hidden email]>:

Ctrl + Home - keystroke '<Cmd-a>' (97)

Ctrl + End - keystroke '<Cmd-d>' (100)

Ctrl + Insert - keystroke '<Cmd-e>'

Ctrl + PageUp - keystroke '<Cmd-k>'
Ctrl + PageDown - keystroke '<Cmd-l>' (108)
Only Ctrl + Delete works ...

Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Freitag, 28. Februar 2020 19:20:30
An: Squeak Dev
Betreff: Re: [squeak-dev] [BUG] Keyhandling on Windows
 

Possibly related issue:

Ctrl + End generates an event like this: keystroke '<Cmd-d>' (100)


Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Freitag, 21. Februar 2020 14:22:18
An: Squeak Dev
Betreff: [squeak-dev] [BUG] Keyhandling on Windows
 

Hi all,


sorry to report to you another, though minor issue related to keyboard handling.


Steps to reproduce:

  • Open a fresh trunk image on Windows
  • turn off num lock (so that 4 works like arrowLeft)
  • Go to any editor, such as workspace
  • Press the number key 5

Expected behavior:
No character is inserted, as digits are turned off.

Actual behavior:
The quotes character (") is inserted.

Notes:
The issue already existed in Squeak 5.2, 4.6 and 3.9 (from my random tests).

Best,
Christoph




Reply | Threaded
Open this post in threaded view
|

Re: [BUG] Keyhandling on Windows

Squeak - Dev mailing list
Same in MacBook, but Enter is shift-Return, in Wolfram Mathematica is used to eval the cell.

> On 4 Mar 2020, at 18:26, Chris Muller <[hidden email]> wrote:
>
> Enter and Return are the same key on US keyboards.  They show the return-arrow graphic AND the word "Enter" printed on them.
>
> I've never known them to be different keys..
>