= character not mapped?

[PaulDaMacMan]

Those darn "modifier" keys, that's the word I was looking for.

Yes yes yes.
I've done quite a bit of fooling around with keyboard chords, both of the musical and of the alpha-numerical variety.

I still don't know where those values originated, perhaps they're descendant from some key code numbering on certain Unix flavors where MetaCard engine began its life running on? I'm not sure why this matters to me either.

[PaulDaMacMan]

So this has bothered me for long enough that I finally made a big push into finding where these key codes came from, and it seems that I was correct in that these key number mappings came from the Unix world, specifically X11 + Digital Equipment Corporation (DEC) + Maynard / MIT, circa 1987.
They're all constants defined in the header file "keysymdef.h" in Hexadecimal.
The F1 function key is defined in that file like so:

Code: Select all

#define XK_F1			0xFFBE

Convert that hex to decimal and we get 65470, which matches the F1 key in my list of the rawKey numbers.
And checking the CapsLock Key:

Code: Select all

#define XK_Caps_Lock		0xFFE5	/* Caps lock */

Converted to decimal = 65509
Mystery solved.

[stam]

I think we’ve probably all wondered about the key codes… excellent detective work!

[richmond62]

Indeed.

AND, as that was a long time before the advent of Unicode that conflict has arisen.

Which is a bit silly as the Unicode chart does have reserved 'slots' for various things, but NOT for any modifier keys.

[stam]

Which is a bit silly as the Unicode chart does have reserved 'slots' for various things, but NOT for any modifier keys.

Glyph to show on screen vs the signal received by keyboard, no?
Modifier keys should not have a unicode glyph?

[richmond62]

Modifier keys should not have a unicode glyph?

No, they should NOT.

BUT if you obtain the rawKey code for the 'up arrow' key you get 65362, which converted into hexadecimal is FF52

and if you check that here:

https://unicode.org/charts/

you get:
-

SShot 2024-04-12 at 12.06.13.png (4.01 KiB) Viewed 1946 times

-
"FF52 ｒ FULLWIDTH LATIN SMALL LETTER R"

It might have been slightly more useful if the Unicode consortium had sat down (on their collective bottom) with a few computer keyboards and someone in the know, and excluded those particular rawKey codes for modifiers and so on from their 'thing'.

[stam]

I realise the futility of crossing posts with you Richmond. But I'll bite anyway:

Modifier keys should not have a unicode glyph?

No, they should NOT.

Yes, thank you Richmond for the response with emphatic capitalised letters, as if I had proposed something silly.
However I was pointing this out to YOU (see? capitals aren't nice), because immediately above, you lamented Unicode not having glyphs for modifier keys:

Which is a bit silly as the Unicode chart does have reserved 'slots' for various things, but NOT for any modifier keys.

BUT if you obtain the rawKey code for the 'up arrow' key you get 65362, which converted into hexadecimal is FF52
<snip>
"FF52 ｒ FULLWIDTH LATIN SMALL LETTER R"

It might have been slightly more useful if the Unicode consortium had sat down (on their collective bottom) with a few computer keyboards and someone in the know, and excluded those particular rawKey codes for modifiers and so on from their 'thing'.

Ermmmm... what?
How is one related to other? The fact that these 2 numbers happen to be the same is an issue... how exactly?
Is it even possible to confuse a rawKeyCode (the signal an external device sends) with a unicode hex??
When was this ever a problem?

I'm gonna say never because the colour of the bread I buy has nothing to do with the color of the plate I put it on, even if they are the exact same Pantone shade...

[PaulDaMacMan]

It might have been slightly more useful if the Unicode consortium had sat down (on their collective bottom) with a few computer keyboards and someone in the know, and excluded those particular rawKey codes for modifiers and so on from their 'thing'.

I don't think that's quite right, they would've had to sit down at a Linux/Unix machine with X11 - X.org XLib. These enum constants numbers come from X11. I could be wrong, maybe with the exceptions of numbers 0 to 127 (ACII) or 0-255 (ASCII Extended), I don't think they'll match the signals/bytes sent from a standard mechanical keyboard (although I might check with a modern USB/Bluetooth keyboard using my HIDAPI wrapper extension). These are what x11 maps the keys to. I have a feeling these are based on something even more ancient like the "Space cadet keyboard" https://en.wikipedia.org/wiki/Space-cadet_keyboard , when there was more 'modifier' keys like 'Hyper','Meta', and others. If you look at that header file it has constants for those obsoleted keys in addition to Control, Shift, Alt, etc. The enums are grouped with comments for different keyboard types, Numeric Pad, ASCII, Latin 1, Latin 2, etc.

I doubt that the people who defined Unicode standards were too worried about backwards compatibility with 1970s LISP machines, but I do agree that it would have been cool of them if they'd reserved those numeric slots, or defined them as producing the symbols that are/were typically printed on the labels of those keys. For example the 'Hyper' key was labeled with an associated glyph, similar to the way Alt/Option is often labeled with that side-ways 'Y' symbol.

[richmond62]

The 'problem', such as it is with the rawKey code for, say, the SHIFT key, coinciding with a Unicode glyph is that were someone wanting to 'get at' that Unicode character might run into some sort of conflict.

Pressing the 'Up Arrow' key results in a raw key code of 65362 (hexadecimal FF52), and, as I have already pointed out the Unciode address FF52 has an 'r' sitting there.

And this:

Code: Select all

put numToCodePoint(65362)

gives us that 'r'.

So, how might one deliver an 'Up Arrow' command programmatically?

Yeah, yeah, yeah: one can fool around with locations and move commands which is far, far more clunky.

[PaulDaMacMan]

The 'problem', such as it is with the rawKey code for, say, the SHIFT key, coinciding with a Unicode glyph is that were someone wanting to 'get at' that Unicode character might run into some sort of conflict.

Pressing the 'Up Arrow' key results in a raw key code of 65362 (hexadecimal FF52), and, as I have already pointed out the Unciode address FF52 has an 'r' sitting there.

And this:

Code: Select all

put numToCodePoint(65362)

gives us that 'r'.

So, how might one deliver an 'Up Arrow' command programmatically?

Yeah, yeah, yeah: one can fool around with locations and move commands which is far, far more clunky.

These large key code numbers have no relationship to unicode numbers, these existed since before 1987, long before Unicode standards came to be, so I'm not sure why you're stuck on that. The only numbers that would jive up with any character glyphs codes are going to be single byte ASCII-defined range.

You can send an Arrow Up to an object (the selectObj or focusedObj for example) in the same way as discussed earlier, like so:
send "rawKeyDown 65362" to the selectedObject -- can be any object
And you can also do same like so:
send "arrowKey up" to the focusedObject -- can be any object

[richmond62]

so I'm not sure why you're stuck on that

Just being awkward.

[dunbarx]

What is this about?

It is spurious to translate a rawKey value into a hex value, and then present the glyph that hex value represents. The plumage don't enter into it.

Craig

[richmond62]

It is spurious to translate a rawKey value into a hex value, and then present the glyph that hex value represents. The plumage don't enter into it.

Is that a fact?

My MacOS 12 iMac is currently connected to a U.S. English keyboard and when I press these keys, I get these rawKey values:

x > 120 > 0x78

W > 87 > 0x57

& > 38 > 0x26

-

-
Now. admittedly, when I set my keyboard layout to 'Sanskrit' (i.e. a keyboard layout that is NOT the same as the one on my mechanical keyboard), and I press the 'W' key I get the rawKey code 87, but I get the Devanagari symbol 'ऐ' which has a Unicode slot numbered 2320 > 0x910.

[Tangentially this shows what an ignorant bunch the lot are who work out and name keyboard layouts for Apple, 'Devanagari' is the name of one of the abugida writing systems that Sanskrit may be written in (it has also been written using 'Grantha', among others), and 'Devanagari' has been used for writing quite a few other Indic languages, so calling a keyboard layout for the Devanagari writing system 'Sanskrit' is just crass.]

[richmond62]

Looking more closely at the Unicode standard one does find that, initially, they took into account the mechanical goings-on of keyboards:
-

-
But, obviously, they lost track of things later on.

[PaulDaMacMan]

"shows what an ignorant bunch the lot are who work out and name keyboard layouts for Apple"
NO, it doesn't, these numbers have little to nothing to do with Apple as these came from X-Windows / Unix, and Unicode didn't exist when computer keyboards started to become standardized around the 104 key IBM layout(s), and so the only keys that might (depending on font / character encoding) have character glyphs that match up to with these numbers are probably going to be in the ASCII range (0-127).
https://www.asciitable.com