Le lun. 16 déc. 2019 à 16:50, K K Subbu <kksubbu.ml at gmail.com> a écrit :

> On 16/12/19 8:24 PM, Marcel Taeumel wrote:
> > The representation of such user-input events is not necessarily specific
> > to Morphic, only that #keyStroke: interface is. In the long term, it
> > would be nice to move "UserInputEvent" etc. out of Morphic into its own
> > base package. This is a matter of finding a consistent, object-oriented
> > representation for user-input events. :-)
>
> Right. key is a physical button while keycode is what is generated by
> keyboard driver. keycode is a low-level numeric code. Morphic should
> only deal with objects like character or selector.
>

Note that there is one more level of distinction:
- for windows, the scancode is the low-level keyboard-specific encoding
(decoded by keyboard driver)
- in windows events the scancode is converted to a virtual keycode, which
is device independent (VK_Enter for Enter key, etc...)
- similarly to virtual keycode, there are keysym on unix (X11)

https://docs.microsoft.com/en-us/windows/win32/learnwin32/keyboard-input
https://docs.microsoft.com/fr-fr/windows/win32/inputdev/about-keyboard-input

The same key on keyboard can generate several characters (a A ä ...),
whether Shift, Alt Gr; or a composition key where pressed, or depending on
status of caps lock, num lock, etc...
The fact that there is a different scancode generated or not when
shift/ctrl is pressed is a low level implementation detail.

We might want to have an OS independant virtual code as charCode for key up
and key down events...
That's already the case for arrows, home, end, page up, page down and a few
other controls...


> > it appears here, CTRL does not only modify a key (character) but
> > actually *modifies* a key (character). :-D Then, again, SHIFT does this,
> > too. Hmmm...
>
> I had to read that a couple of times to understand it ;-). CTRL modifies
> a keycode not a character. It was introduced to accommodate the
> limitations of a physical keyboard. This is why soft keyboards (like the
> ones on smartphones) don't need one.
>
>   https://en.wikipedia.org/wiki/Control_key
>   https://en.wikipedia.org/wiki/Alt_key
>
> Regards .. Subbu
>
> This was the case on legacy keyboard for legacy apps (typewritter and
console apps)
Nowadays CTRL modifies the WM_CHAR event, but the keycode remains unchanged
for WM_KEYDOWN and WM_KEYUP events...
So it's not the virtual keycode which is modified! (maybe the scancode, we
don't care, too low level)

The idiomatic handling CTRL may vary on different OS: windows recommend
handling control+key shortcuts at keydown event, and more idiomatically
thru AcceleratorTable...
https://docs.microsoft.com/en-us/windows/win32/learnwin32/accelerator-tables
Probably not universal enough for being in the VM...

Do we really want to generate Start of Heading control code with the
keyboard for Squeak consumption? i doubt... If we would want that, we would
emulate it.
But we probably want to be able to distinguish CTRL+M from
Control+Enter/Return...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191216/8194874d/attachment.html>