Horrible mess in keyboard modifiers processing

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

Horrible mess in keyboard modifiers processing

Pavel Krivanek-3
On Linux and Windows, the keyboard usage is very limited, especially in combination with the mouse. There is no way how to invoke any key corresponding to Mac command key (⌘). As result there are is no option how on these platforms select several nonadjacent methods in Calypso to display them at once and you cannot click on a method selector to reach the implementation.

I tried to log modifiers on input events on all three platforms and this is the sad result:

Mac:
shift 0 1 1 0
ctrl 0 2 2 0
option (⌥) 0 4 4 0
command (⌘) 0 8 8 0 

The numbers are in order:
 - modifier key pressed
 - mouse down
 - mouse up
 - modifier key released

So on Mac the mouse events are processed correctly but the events related keyboard have no modifiers flags.

Linux:
shift 0 1 1 0
ctrl 0 0 2 0
win  - 0 0 -
alt 0 - - 0 
altgr - 0 0 -

So on Linux the Shift key is processed correctly, The Ctrl key does not have correct modifier flag when the mouse is pressed (which is strange because the combination of Shift+Ctrl returns 0 3 3 0). Win key changes click behavior to right mouse button. For Alt the mouse events are not detected at all and AltGr behaves as Win except the right mouse button simulation. The keyboard event modifiers are not set.

Windows:
shift 16 1 1 1 16
ctrl 17 2 2 2 17
win - 0 0 0 -
alt 18 8 8 8 18
altgr 18 8 8 8 18

Windows as the only platform set modifiers for keyboard events. The mouse button release generates two events, Win key changes behavior to right mouse button, and Alt behaves the same way as AltGr.

Cheers,
-- Pavel


Reply | Threaded
Open this post in threaded view
|

Re: Horrible mess in keyboard modifiers processing

Peter Uhnak
Btw I've opened an issue for this (for linux) last month https://pharo.fogbugz.com/f/cases/21732/left-click-ctrl-is-unsuable-on-Linux

The Ctrl key does not have correct modifier flag when the mouse is pressed

Note in the linked issue, that the modifier is present on mouseUp. My understanding is that mouseDown it is being replaced by a different event somewhere inside Pharo (maybe the mentioned InputEventSensor class>>swapMouseButtons ?)

Peter

On Mon, May 28, 2018 at 6:02 PM, Pavel Krivanek <[hidden email]> wrote:
On Linux and Windows, the keyboard usage is very limited, especially in combination with the mouse. There is no way how to invoke any key corresponding to Mac command key (⌘). As result there are is no option how on these platforms select several nonadjacent methods in Calypso to display them at once and you cannot click on a method selector to reach the implementation.

I tried to log modifiers on input events on all three platforms and this is the sad result:

Mac:
shift 0 1 1 0
ctrl 0 2 2 0
option (⌥) 0 4 4 0
command (⌘) 0 8 8 0 

The numbers are in order:
 - modifier key pressed
 - mouse down
 - mouse up
 - modifier key released

So on Mac the mouse events are processed correctly but the events related keyboard have no modifiers flags.

Linux:
shift 0 1 1 0
ctrl 0 0 2 0
win  - 0 0 -
alt 0 - - 0 
altgr - 0 0 -

So on Linux the Shift key is processed correctly, The Ctrl key does not have correct modifier flag when the mouse is pressed (which is strange because the combination of Shift+Ctrl returns 0 3 3 0). Win key changes click behavior to right mouse button. For Alt the mouse events are not detected at all and AltGr behaves as Win except the right mouse button simulation. The keyboard event modifiers are not set.

Windows:
shift 16 1 1 1 16
ctrl 17 2 2 2 17
win - 0 0 0 -
alt 18 8 8 8 18
altgr 18 8 8 8 18

Windows as the only platform set modifiers for keyboard events. The mouse button release generates two events, Win key changes behavior to right mouse button, and Alt behaves the same way as AltGr.

Cheers,
-- Pavel



Reply | Threaded
Open this post in threaded view
|

Re: Horrible mess in keyboard modifiers processing

Guillermo Polito
He, i think this may be a VM issue. I've fixed part of the keyboard event handling in the past, but it's effectively a mess...

On Tue, May 29, 2018 at 9:45 AM, Peter Uhnák <[hidden email]> wrote:
Btw I've opened an issue for this (for linux) last month https://pharo.fogbugz.com/f/cases/21732/left-click-ctrl-is-unsuable-on-Linux

The Ctrl key does not have correct modifier flag when the mouse is pressed

Note in the linked issue, that the modifier is present on mouseUp. My understanding is that mouseDown it is being replaced by a different event somewhere inside Pharo (maybe the mentioned InputEventSensor class>>swapMouseButtons ?)

Peter

On Mon, May 28, 2018 at 6:02 PM, Pavel Krivanek <[hidden email]> wrote:
On Linux and Windows, the keyboard usage is very limited, especially in combination with the mouse. There is no way how to invoke any key corresponding to Mac command key (⌘). As result there are is no option how on these platforms select several nonadjacent methods in Calypso to display them at once and you cannot click on a method selector to reach the implementation.

I tried to log modifiers on input events on all three platforms and this is the sad result:

Mac:
shift 0 1 1 0
ctrl 0 2 2 0
option (⌥) 0 4 4 0
command (⌘) 0 8 8 0 

The numbers are in order:
 - modifier key pressed
 - mouse down
 - mouse up
 - modifier key released

So on Mac the mouse events are processed correctly but the events related keyboard have no modifiers flags.

Linux:
shift 0 1 1 0
ctrl 0 0 2 0
win  - 0 0 -
alt 0 - - 0 
altgr - 0 0 -

So on Linux the Shift key is processed correctly, The Ctrl key does not have correct modifier flag when the mouse is pressed (which is strange because the combination of Shift+Ctrl returns 0 3 3 0). Win key changes click behavior to right mouse button. For Alt the mouse events are not detected at all and AltGr behaves as Win except the right mouse button simulation. The keyboard event modifiers are not set.

Windows:
shift 16 1 1 1 16
ctrl 17 2 2 2 17
win - 0 0 0 -
alt 18 8 8 8 18
altgr 18 8 8 8 18

Windows as the only platform set modifiers for keyboard events. The mouse button release generates two events, Win key changes behavior to right mouse button, and Alt behaves the same way as AltGr.

Cheers,
-- Pavel






--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: Horrible mess in keyboard modifiers processing

philippeback
I think that we could address this by using left or right Alt/Ctrl to emulate Cmd.

There is no way out of the fact that the Mac has some that Cmd key. 

We have a Windows key but it is out of reach for most of the usages.

Capslock comes to mind...

Phil


On Tue, May 29, 2018 at 9:58 AM, Guillermo Polito <[hidden email]> wrote:
He, i think this may be a VM issue. I've fixed part of the keyboard event handling in the past, but it's effectively a mess...

On Tue, May 29, 2018 at 9:45 AM, Peter Uhnák <[hidden email]> wrote:
Btw I've opened an issue for this (for linux) last month https://pharo.fogbugz.com/f/cases/21732/left-click-ctrl-is-unsuable-on-Linux

The Ctrl key does not have correct modifier flag when the mouse is pressed

Note in the linked issue, that the modifier is present on mouseUp. My understanding is that mouseDown it is being replaced by a different event somewhere inside Pharo (maybe the mentioned InputEventSensor class>>swapMouseButtons ?)

Peter

On Mon, May 28, 2018 at 6:02 PM, Pavel Krivanek <[hidden email]> wrote:
On Linux and Windows, the keyboard usage is very limited, especially in combination with the mouse. There is no way how to invoke any key corresponding to Mac command key (⌘). As result there are is no option how on these platforms select several nonadjacent methods in Calypso to display them at once and you cannot click on a method selector to reach the implementation.

I tried to log modifiers on input events on all three platforms and this is the sad result:

Mac:
shift 0 1 1 0
ctrl 0 2 2 0
option (⌥) 0 4 4 0
command (⌘) 0 8 8 0 

The numbers are in order:
 - modifier key pressed
 - mouse down
 - mouse up
 - modifier key released

So on Mac the mouse events are processed correctly but the events related keyboard have no modifiers flags.

Linux:
shift 0 1 1 0
ctrl 0 0 2 0
win  - 0 0 -
alt 0 - - 0 
altgr - 0 0 -

So on Linux the Shift key is processed correctly, The Ctrl key does not have correct modifier flag when the mouse is pressed (which is strange because the combination of Shift+Ctrl returns 0 3 3 0). Win key changes click behavior to right mouse button. For Alt the mouse events are not detected at all and AltGr behaves as Win except the right mouse button simulation. The keyboard event modifiers are not set.

Windows:
shift 16 1 1 1 16
ctrl 17 2 2 2 17
win - 0 0 0 -
alt 18 8 8 8 18
altgr 18 8 8 8 18

Windows as the only platform set modifiers for keyboard events. The mouse button release generates two events, Win key changes behavior to right mouse button, and Alt behaves the same way as AltGr.

Cheers,
-- Pavel






--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13


Reply | Threaded
Open this post in threaded view
|

Re: Horrible mess in keyboard modifiers processing

Nicolas Cellier
In reply to this post by Guillermo Polito


2018-05-29 9:58 GMT+02:00 Guillermo Polito <[hidden email]>:
He, i think this may be a VM issue. I've fixed part of the keyboard event handling in the past, but it's effectively a mess...

Yes, there are some issues opened already

Feel free to complete or open new ones if necessary.