A couple of keyboard event issues (was Re: [Vm-dev] [Windows cog vm] [Keyboard events related] about keycode mapping)

Guillermo Polito guillermopolito at gmail.com
Fri Jan 27 04:53:21 UTC 2012

For the Windowze problem, here a Guy wrote down all the problems he found:



On Thu, Jan 26, 2012 at 10:42 PM, Juan Vuletich <juan at jvuletich.org> wrote:

> Hi Folks,
> This is actually sort of unrelated, but I'm answering to this thread just
> because this is also about how VMs report keystrokes in different
> platforms. There are 2 things really don't like. It would be great to have
> these fixed on the official VMs.
> On the mac, when control or command are pressed, for any keystroke the
> unshifted code is returned, even if shift is pressed. For instance, let's
> assume an US keyboard. So, [shift]+[,] generates $< and [shift]+[.]
> generates $>. If you run 'Sensor kbdTest' and press [shift]+[,] you
> correctly get $<, but if you press [control]+[shift]+[,] or
> [command]+[shift]+[,] you get $,. This is bad, because to detect
> [command]+[<] or [control]+[<] you need to write code that not only needs
> to know about the platform, but also about the keyboard layout, as in many
> layouts $< is not generated by doing [shift]+[,], but by some other
> combination. The same happens with most non-alphabetic keys, that usually
> differ in different keyboard layouts.
> There is a completely separated issue, and it happens both in Windows and
> Mac. Here, [ctrl] + [an alphabetic key] substracts 64 from the code. So,
> [ctrl]+[c] generates code 3. This is consistent with the traditional
> meaning of the ctrl key (in dumb terminals and DOS), but it makes
> impossible for the image to tell (for example) between [ctrl]+[Enter] and
> [ctrl]+[m]. The image might want to use these keystrokes for different
> things, so it would be much better not to substract 64 in the VM and let
> the image handle it. I know it could be done by handling key down and key
> up events, but this would also require code that is not only platform
> dependent but also needs to know the mapping between key codes and
> characters in each platform.
> In general, I think that [control], [command] and [alt/option] should not
> affect the character code of a keystroke, they should only set the
> appropriate flag so the image can decide what to do with them. This is
> completely different for [shift], as [shift] does indeed modify the
> character generated.
> I haven't tested on Linux or other platforms, but things like these could
> also happen.
> Fixing these would enable a few simplifications in the image (at least in
> Cuis) and also ease consistent behavior in different platforms. It would
> also enable the use of some keystroke combinations involving [command]
> and/or [control] that are problematic today.
> Thanks,
> Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120127/bcfe5639/attachment-0001.htm

More information about the Vm-dev mailing list