Terry J. Reedy <tjre...@udel.edu> added the comment: This is a duplicate of #31244, but I continue here with more experiments using the code above. I first confirmed that on Windows, CapsLock is really 'caps inversion. Keycode 67 is the keycode for 'C' given in https://www.tcl.tk/man/tcl/TkCmd/keysyms.html (Ascii keyboards have the capitals on keycaps), but the chars 'c' and 'C', without and with shift, are 4 different events.
char: c, ord: 99, code: 67, sym: c, num: 99. code: 16, sym: Shift_L, num: 65505. char: C, ord: 67, code: 67, sym: C, num: 67. code: 20, sym: Caps_Lock, num: 65509. char: C, ord: 67, code: 67, sym: C, num: 67. code: 16, sym: Shift_L, num: 65505. char: c, ord: 99, code: 67, sym: c, num: 99. Next, the same keypresses with Ctrl added. At least on Windows, Ctrl+c, Shift+Ctrl+c, Ctrl+C, and Shift+Ctrl+C are different events that have the same Ascii code but are differentiated by the key sym that would have been generated without the control modifier and the state of the Shift key. (Note, for instance, that on the file menu, the addition of 'Shift' modifies 'Save' to 'Save as'). code: 17, sym: Control_L, num: 65507. char: , ord: 3, code: 67, sym: c, num: 99. code: 17, sym: Control_L, num: 65507. code: 16, sym: Shift_L, num: 65505. char: , ord: 3, code: 67, sym: C, num: 67. code: 20, sym: Caps_Lock, num: 65509. code: 17, sym: Control_L, num: 65507. char: , ord: 3, code: 67, sym: C, num: 67. code: 17, sym: Control_L, num: 65507. code: 16, sym: Shift_L, num: 65505. char: , ord: 3, code: 67, sym: c, num: 99. I loaded the Win 10 Russian package. Repeating the no-ctrl block, we get the Cyrillic с and С. The keysym field is '??' instead of the char because non-ascii letters are not valid as keysyms. The keysym_num field is correct as if the keysym were the non-ascii letter. char: с, ord: 1089, code: 67, sym: ??, num: 1089. code: 16, sym: Shift_L, num: 65505. char: С, ord: 1057, code: 67, sym: ??, num: 1057. code: 20, sym: Caps_Lock, num: 65509. char: С, ord: 1057, code: 67, sym: ??, num: 1057. code: 16, sym: Shift_L, num: 65505. char: с, ord: 1089, code: 67, sym: ??, num: 1089. With Ctrl added, the generated character is still ascii 3, control-C and the keycode is still 67. But the keysym and keysym_num are changed and they no longer match neither ascii 'c' or 'C'. So the event matches neither the control-c or control-C events and the copy event is not invoked. code: 17, sym: Control_L, num: 65507. char: , ord: 3, code: 67, sym: ??, num: 1089. code: 17, sym: Control_L, num: 65507. code: 16, sym: Shift_L, num: 65505. char: , ord: 3, code: 67, sym: ??, num: 1057. code: 20, sym: Caps_Lock, num: 65509. code: 17, sym: Control_L, num: 65507. char: , ord: 3, code: 67, sym: ??, num: 1057. code: 17, sym: Control_L, num: 65507. code: 16, sym: Shift_L, num: 65505. char: , ord: 3, code: 67, sym: ??, num: 1089. The workaround considered in #31244 was to add key-x bindings specific to a particular Windows IME. But this does not work as key sequences only allow ascii alphanumerics as keysyms. (See https://www.tcl.tk/man/tcl8.6/TkCmd/bind.html, event details.) There are non-ascii letter descriptions, such as 'Cyrillic_es' listed in https://www.tcl.tk/man/tcl/TkCmd/keysyms.html, but I suspect that these only work for native keyboards, with the non-ascii chars on the keycaps, that generate the keycodes specific to each key as listed in that doc. Cyrillic_es has keycode 1747, not 67. When I tried binding '<Key-Cyrillic_es>' there was no TclError, but a Russian es, 'с' or 'С', did not invoke the handler. Instead of expanding keybindings, we should consider collapsing events to undo the IME translation. '??' is not a valid keysym, so there seems to be no generic 'non-Ascii IME letter' event. But we could try replacing the keysym with the ascii char that would have been there if there were no IME. The problem is that modifying the python event will not change the tk event. Nor can it be used with event_generate. Rather it has to be turn back into 'sequence' string, taking into account the .state attribute. Automated testing would be done by calling the key event handler with a synthesized Event instance. EP: Since Key-X, where x is a non-ascii char, in not a legal sequence and cannot be bound to anything, it seems reasonable to ask that tk itself translate control key events into bindable control sequences. They might object that this would break any code that catches '??' events in generic key handlers to do something language specific. But perhaps they could add a non-default option. ---------- assignee: -> terry.reedy stage: -> test needed versions: +Python 3.11 -Python 3.9 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue46052> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
