Horrible mess in keyboard modifiers processing
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
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 <pavel.krivanek@gmail.com> 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
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 <i.uhnak@gmail.com> 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 <pavel.krivanek@gmail.com> 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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
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 <guillermopolito@gmail.com
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 <i.uhnak@gmail.com> wrote:
Btw I've opened an issue for this (for linux) last month https://pharo.fogbugz.com/f/cases/21732/left-click-ctr l-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 <pavel.krivanek@gmail.com
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 <http://www.cnrs.fr>*
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13
2018-05-29 9:58 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>:
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 https://github.com/OpenSmalltalk/opensmalltalk-vm/issues?utf8=%E2%9C%93&q=is... https://github.com/OpenSmalltalk/opensmalltalk-vm/issues?utf8=%E2%9C%93&q=is... Feel free to complete or open new ones if necessary.
participants (5)
-
Guillermo Polito -
Nicolas Cellier -
Pavel Krivanek -
Peter Uhnák -
phil＠highoctane.be