For the Windowze problem, here a Guy wrote down all the problems he found:<br><br><a href="http://www.ngedit.com/a_wm_keydown_wm_char.html">http://www.ngedit.com/a_wm_keydown_wm_char.html</a><br><br>Guille<br><br><div class="gmail_quote">
On Thu, Jan 26, 2012 at 10:42 PM, Juan Vuletich <span dir="ltr"><<a href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hi Folks,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I haven't tested on Linux or other platforms, but things like these could also happen.<br>
<br>
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.<br>
<br>
Thanks,<span class="HOEnZb"><font color="#888888"><br>
Juan Vuletich<br>
</font></span></blockquote></div><br>