I’ve update the document with the last code changes that are soon to be merged, I’ve extended my tests to include azerty layout too.
First, it is already looking much better, with more consistent keycodes and keysyms accross OSes. I remarked a few more things:
- Testing and keysyms on Win/MacOS
KeySym on windows and MacOS are not provided by the OS but builtin VTK based on the different OS provided keycodes. This explains why quoteright which is not even part of the Latin1 ASCII is listed there. It is a very easy fix, which I will take care of.
However it raises the question of testing. Currently the logic the translate a OS virtual key code into an actual keyCode and keySym is completely untested in VTK. Indeed, VTK testing system interface itself just after that.
I will investigate the possiblity of adding simple or even exhaustive testing of this layer.
- ASCII vs Latin1 support
Xorg implementation always nativaly supported Latin1 (ISO/IEC 8859-1 - Wikipedia) for KeyCode and KeySym, while Win32 supported it for KeyCode only and macOS did not support it at all. I’ve added support for KeyCode in MacOS as it was trivial but in order to support KeySym too, more work is needed.
Indeed, there are big translation tables from KeyCode to KeySym in MacOS and Win32. I will try to complete them but the process may prove hard, especially without testing.
Also, the value of these >=128 Latin1 keycode are currently negative as the API is using a char. This must change.
- Cross platform interaction
While Windows and Linux are quite respectful of the keyboard layout standard, MacOS does what MacOS do with custom keyboard and such, so the modifiers and layouts are slightly different.
Which means that certains combination of keys using Alt modifier will just not be available. You won’t be able to get Alt modifier with a keycode, because Alt + a on a MacOS is Å.
In a way, this is expected and visible on the physical key itself. If the user pressed the same combination of key in a text editor, the will get the Å as well!
But it also means that, when coding a cross platform widget in VTK, you cannot expect your interactions to work on all layout and all OSes.
One solution is to provide full configuration of the interaction. While this is usually possible at application level, this is not really an option in VTK Widgets.
This is where the API I suggested above start to make complete sense. For cross platform widgets, one absolutaly needs keycodes without modifiers. It is not bullet proof but way more stable accross layout and OSes. Basically the whole alphabet [a-z] would become fully cross-layout and cross-platform.
So I now believe this API addition is indeed required.