Tk Source Code

Hi there.
On my MacOS 10.14.16 laptop with a qwerty keyboard I was testing tkinter keyboard listening for an azerty keyboard layout by switching the layout to `French - PC`
When I press qwerty keys Shift + \ I expect to see 'μ' printed.
When looking at the tkinter events for that key press we see:
```
down {'keysym': 'Shift_L', 'keysym_num': 65505, 'keycode': 131072, 'char': ''}
down {'keysym': 'tslash', 'keysym_num': 956, 'keycode': 956, 'char': 'μ'}
up {'keysym': 'asterisk', 'keysym_num': 42, 'keycode': 2753468, 'char': 'μ'}
up {'keysym': 'Shift_L', 'keysym_num': 65505, 'keycode': 131072, 'char': ''}
```
So the char value is correct but the keysym_num is not the expected 181 for mu.
Comparing this to pressing Shift + / to generate the section symbol (§) we see:
```
down {'keysym': 'Shift_L', 'keysym_num': 65505, 'keycode': 131072, 'char': ''}
down {'keysym': 'section', 'keysym_num': 167, 'keycode': 167, 'char': '§'}
up {'keysym': 'section', 'keysym_num': 167, 'keycode': 2883751, 'char': '§'}
up {'keysym': 'Shift_L', 'keysym_num': 65505, 'keycode': 131072, 'char': ''}
```
python.org people directed me to open this ticket here per:
https://bugs.python.org/issue42695

Closing this ticket as the problem has been fixed and the fix will be included
in the coming 8.6.11 release.

OK.  Now that I am on the same page as you are, I can tell you that you are
reporting issues which existed in the old Tk 8.6.8 that python.org is still
shipping as the embedded Tk in the macOS release.  These issues have been
fixed in newer releases of Tk.  Tk 8.6.11 is close to being released at this
moment and I understand that Python plans to include it in future Python
releases.  Please encourage them to follow up on that plan.

Here is what I saw in Wish using the 8.6.11 release candidate.  I first ran:

% bind . <KeyPress> {puts "Press: keysym = %K; keycode = %k; char = %A"}
% bind . <KeyRelease> {puts "Release: keysym = %K; keycode = %k; char = %A"}

The I switched to the French-PC keyboard and typed the shifted slash and
backslash characters.  The result was as follows:

Press: keysym = Shift_L; keycode = 943782142; char = {}
Press: keysym = Greek_mu; keycode = 708838332; char = μ
Release: keysym = Greek_mu; keycode = 708838332; char = μ
Release: keysym = Shift_L; keycode = 939587838; char = {}
Press: keysym = Shift_L; keycode = 943782142; char = {}
Press: keysym = section; keycode = 742391975; char = §
Release: keysym = section; keycode = 742391975; char = §
Release: keysym = Shift_L; keycode = 939587838; char = {}

So all that needs to be done is for Tk 8.6.11 to be released and for Python.org
to start using it.

And you are correct, there were lots of bugs related to keysyms and keycodes
in older versions of Tk.  It took some effort to fix them, but that was done
some time ago.

Thank you for explaining the differences between different mus.
My concern is not about which mu I get back, it is with the fact that the keysym and keysym_num values:
- do not agree with eachother (956 != 42) for the 2nd and 3rd key press and release. I expect their values to be the same like we see with the section symbol example (167 == 167).
- the keysym_num values for a mu key press do not describe a mu. 956 describes tslash and 42 describes asterisk. Per your comment, I expect the keyup and keydown keysym_num values to be 1996. Again looking at the section when the qwerty forward slash button is pressed we see the correct keysym_num of 167, rather than the lowercase key value of 33 for '!'.

I should mention that the reason why Greek_mu is generated rather than
mu is that the unicode character in the Apple NSEvent generated for that
keypress is U03bd, not U00b5.  The data file referenced in my previous
comment indicates that U03bd corresponds to Greek_mu while U00b5 corresponds
to mu.

You are getting the keysym number for Greek_mu instead of the keysym
number for mu.  Why do you expect mu instead of Greek_mu?

The data used in macOSXKeysym.h comes from:
 http://www.cl.cam.ac.uk/~mgk25/ucs/keysyms.txt