On Mon, 20 Dec 2021 12:11:11 GMT, Johan Vos <j...@openjdk.org> wrote:
>> Martin Fox has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains five additional >> commits since the last revision: >> >> - Merge branch 'master' into macshortcut >> - Fixed whitespace error. >> - A small number of keyboard layouts require the Option key to reach >> critical letters like 'Q'. Added a third probe (after Command and >> Shift+Command) to look for letters that require Option. The >> keyboards in question are Azeri, Turkmen, and the Sami layouts. >> - The code now queries both the shifted and unshifted characters for a key >> favoring digits and letters over everything else. This ensures we catch >> the digits on the French layout without interfering with Dvorak. >> - Mac - generate KeyCodes that match user's active keyboard layout. > > This looks ok, but I'm still a bit worried about possible regression. I > understand that rigorous automated tests are hard in this case, but I wonder > if we can have some basic tests at least. > Is there an issue in the Robot implementation preventing this? @johanvos I thought about your questions some more and decided to expand my KeyboardTest app. A new version is attached. The tests now cover as many keys as possible on German, French, and U.S. English layouts on Windows, Mac, and Linux. There are also tests for generic Latin and non-Latin layouts that check for proper behavior of KeyCodes A through Z, namely that they always generate characters and on Latin layouts those characters are ‘a’ through ‘z’. The tests don’t cover dead keys or the top-row function keys because there’s too much variation across platforms. They also can’t cover keys that aren’t assigned KeyCodes like accented character keys. On Windows and Linux the biggest barrier to testing is the buggy Robot code. If you want to use this test app on Windows you’ll need to pull down PR #702. I’ll submit a PR for Linux this week. For now I would avoid the combination tests because they fail more often than not (but I’m working on that with PR #694) and aren't related to this PR. If we assume a Latin keyboard we can easily automate testing for about 60 keys (letters, portions of the keypad, Space, Tab, Home, End, and so on). I’ll look into creating an expanded automated test. But I still have no good plan for addressing punctuation and symbols which is historically where most of the bugs have been and the tests will only be useful if they are regularly run on a variety of different keyboard layouts. I'm not sure what to do with this test app. I would like to get it into the codebase since it’s useful for testing Robot fixes but there are three PR’s involved, this one for Mac, #702 for Windows, and an upcoming one for Linux. [KeyboardTest.txt](https://github.com/openjdk/jfx/files/7800066/KeyboardTest.txt) ------------- PR: https://git.openjdk.java.net/jfx/pull/425
