I was able to borrow a full USB keyboard and do some tests on my Mac...
Geoff the Medio wrote:
...it's apparently converting the 7 and 1 keypad presses into HOME and END keypresses in Edit, since it thinks numlock is off.
That's exactly what happens. "numlock_on" evaluates to "false" in Edit::KeyPress, so the GGK_KPx keycodes get translated.
These are the results of my tests:
Numeric keypad keys behaviour without
your patch: ENTER, "=", "/", "*", "-", "+" work normally (as they should). All the other keys do nothing.
Numeric keypad keys behaviour with
your patch: ENTER, "=", "/", "*", "-", "+" work normally (as they should). "7" acts as HOME, "1" as END, "4" as LEFT, "6" as RIGHT, keypad period as DELETE. "8", "2", "9" and "3" do nothing, but I'm sure that's because we're inside a single line edit control. "5" and "0" do nothing.
The strange key above "7" was numlock on older Macs, as I found out in the meantime. Apparently this function was dropped some time ago (so modern Mac keyboards don't have numlock anymore), now this key's supposed function is to act as the "Clear" key in the Calculator app (I googled this one). Further testing revealed that it apparently doesn't do anything in other applications. Why it acted like DELETE when I first tested it (I think in LibreOffice) I don't know, I couldn't reproduce this behaviour.
When you press this key in FO, nothing happens. However, with the other numeric keypad keys at least Edit::KeyPress gets called, with this "Clear" key not even that happens. It's like no key is been pressed at all. As it seems to be ignored by other apps except Calculator, this shouldn't be a problem.
So, the expected behaviour on Mac would be that "Clear" does nothing, while the rest of the numeric keypad keys act like numlock is on. As on Mac the numeric keys on the numeric keypad apparently aren't recognized, I'd suggest to implement an OSX specific code section in Edit::KeyPress translating the GGK_KPx key codes in question. The period key is a bit of a challenge, because depending on the keyboard used this is either a period or a comma. As the keyboard layout in FO is fixed on US QWERTY at the moment, we can just translate it to ".", but once that changes we have to keep in mind that this has to be adapted correctly in Edit::KeyPress too. If you're ok with that suggestion, I can do it if you want.
While debugging Edit::KeyPress I came across another issue that I've been noticing before. On OSX, when you hide the FO application and bring it back to front (and also when you minimize it to the dock and bring it back), edit controls no longer work correctly. You can delete characters, but can't type new ones. Which is quite annoying of course. The reason is that after hiding/unhiding (minimizing/bringing back up) the Edit::KeyPress parameter mod_keys contains values indicating that one of CTRL, ALT or META (CMD on Mac, WIN on Windows) has been pressed, even if that's not the case. The values seem to vary, one time private member mod_keys.m_flags was set to 64 (when I tried minimizing and bringing back up), another time to 1024 (when I tried hiding/unhiding).
I've no idea why this happens, but at least it's something to start with, if someone wants to look into this issue. I'd do it myself, but I'm a bit out of my depth here.