I’m having an issue with GDK returning incorrect keysyms when using the numeric keypad on Windows: when I press ‘Home’ on the keypad (numlock off) Linux correctly returns KP_Home, but Windows returns Home, same goes for other ‘special’ keys such as KP_End, KP_Page_Down, etc, these return their non-KP_ equivalents.
Is this a known issue? Couldn’t find anything about this on GitLab and asked on IRC, but it seems the mention of ‘Windows’ scared people away.
Perhaps there’s some workaround for this, at least until this gets fixed? Maybe something along the lines of redefining macros when a certain GDK-version is lower than the eventual fixed GDK?
We need to able to differentiate between Home and KP_Home (and others) to allow our virtual keymaps to work (mapping a PC keyboard’s positional key matrix to something that resembles a CBM PET keyboard, among others).
I will,but I’ll wait a bit, see if any useful answers turn up here.
I took a glance at the GDK Win32 code, and I’m not seeing any opportunities to redefine macros to ‘fix’ issues, I probably saw some ancient Gtk2 bug report where there where a few checks via macros to determine what key was pressed. The current code seems to get a keymap from Windows and then somehow map that to GDK, apparently making a few mistakes.
I’m not a Windows dev, at all, so I’d rather not get involved in fixing this upstream. Our SDL2 port correctly handles the numpad keys, so this seems to be a GDK bug on Windows.
You can download a nightly build from https://vice.pokefinder.org/. If you run x64sc.exe (the C64 emulator), you can go into settings (Alt+O) and then select “Input devices -> Keyboard” where you can toggle the “keyboard debugging”. which will provide some info on the keyboard handling on the statusbar.
On Linux when I press the keypad Home/7 key I get 0xff95 / KP_Home, but just Home on Windows. I cannot look up the actual code since I wiped Windows.
On Linux when I press Home it correctly sends ‘Home’ to the emulated C64 and when I press Home on the keypad, nothing happens, which is correct, since GDK_KEY_Home is mapped to the emulated C64’s CLR/HOME key and not GDK_KEY_KP_Home. On Windows GDK_KEY_KP_Home is sent as GDK_KEY_Home to the emulator, which triggers CLR/HOME.
With the C64, this isn’t much of a problem, it doesn’t have a keypad and the KP_0 - KP_9 codes do work correctly, so we can emulate a joystick via those keys. With machines like the C128, PET and CBM-II, which do have a keypad, the incorrectly scanned keys (or rather the mapping of whatever Windows returns to GDK), this becomes a problem and makes it hard to provide working positional keymaps for the machines I just mentioned.
As said, it works fine on Linux, and I’m waiting on reports about MacOS. On Windows, both compiled via msys2 on Windows and cross-compiled on Debian, it fails.
I know it is not related to your problem, but from my GTK(beginner) side it looks like, that the source code of your application is a C code rather then working with GTK.
You should subclass those repeating Widgets instead of C style.
There are a lot of functions which calls another functions, which …
You should concentrate more on subclassing Widgets by creating new ones.
I am just saying.
We do indeed use C, so subclassing is out. There are ways to ‘subclass’ widgets using a lot of macros in Gtk, but I found that more trouble than it’s worth. I do use OOP-ish constructs and ‘composition’, if you can call it that when using C.
Should I have been using C++ or Python, I probably would have subclassed certain simple widgets because those language have proper support for that.
As far as our project being C rather than Gtk: we use Gtk3 for one of our UI’s (on any ‘modern’ OS that supports Gtk3), most of the core (emulation) code is ‘plain’ C, using various libs for sound, graphics, input/output etc. If you take a look at src/arch/gtk3, you’ll notice plenty of Gtk3/GDK/GLib code. Likewise you’ll notice a lot of SDL code in src/arch/sdl. We used to have code for win32, cocoa, gtk2 and xaw, but we dumped that in favour of Gtk3.
The way how I see the things is that on Windows (i have no windows to test it) you get another number which is different from the one reported by event->keyval on Linux.
So if I am right and you print the event->keyval with the %u specifier you will notice it.
This means that the problem is not the gdk_keyval_from_name().
The problem is that on windows event->keyval reports a different key which is definitely not the same on Linux.
Yes, you’re basically repeating what I said in the original post . It’s most likely a bug on Windows since it works fine on Linux. And using the invalid GDK keyval will obviously return an invalid string representation and vice-versa.
I’ll take this to GitLab, this discussion isn’t helpful at all.
I’m not being rude, I’m just explaining that the answers I got so far, which I’m sure are well meant, don’t help me.
For example:
the source code of your application is a C code rather then working with GTK.
You should subclass those repeating Widgets instead of C style.
That, and I’m trying to be very friendly here, indicates to me you do not have a firm grasp of various concepts when it comes to working with Gtk or any other toolkit/library and how each programming language will/might a have different way of interfacing with those toolkits/libraries.
And if you think I’m rude, you probably haven’t been on usenet, back when it was still somewhat useful.
Bumping this. Someone surely would know why this stuff works on Linux and not on Windows or MacOS?
From what I’ve seen of the Gtk/GDK code it doesn’t go ‘deep’ enough into the Win32 API, ie the VK_* stuff is too high level. I suspect something similar happens on MacOS.
I’ve been told this will be ‘solved’ with Gtk4, but since that’s not ready for general use/release, I’m stuck with Gtk3. So perhaps someone has a solution for this? Preferably something portable, ie Gtk/GLib/GDK/GIO-based, but if that doesn’t work perhaps some arch-dependent code that somehow produces Gtk/GLib objects I can use in a non-arch manner?