GNOME Bugzilla – Bug 555522
Problem with KP_DECIMAL
Last modified: 2018-04-15 00:32:43 UTC
Hello everybody, On win32, the KP_SEPARATOR on the numpad doesn't write the correct separator of my regional options. It writes a "." though in France, I need a ",". My regional options seems correct : http://www.zimagez.com/zimage/capture-1121.php
what is the result of =getenv("LANG")?
What does the key insert when you use it in a text field? (Use the Find dialog for testing, for example.)
it inserts a dot, which, in that case is the normal behavior, imho. I can reproduce this bug, but I don't understand why it occurs. It would probably some debugging I'm not able to do on win32.
If it inserts a dot in a text field, doesn't that tell us that gtk+ is at fault?
I'm not sure, but I'm suspecting gdk or gtk. But I could not find why. gdkkeys-win32.c maps VK_SEPARATOR to GDK_KP_Separator which is correct.
Gdk is indeed returning 46 rather than KP_Separator
Looks like we need to test the hardware code when gdk returns 46 (win32 only, of course). Unless it can be fixed in gdk, but I doubt.
Testing hardware codes is a lost cause. They can and will change between keyboards. Any reason why this could not be fixed in gdk? (Beyond the general bug-fixing-is-boring attitude over in gdk land.)
Well the key returning KP_DECIMAL has a hardware code generally > 80 while the dot is < 60 or so. I would, of course, prefer a fix in gdk. As I don't have any documentation on the win32 API, I can't make a patch. That's why I propose a hack which, as bad as it is, should work for most users.
Created attachment 120612 [details] [review] Add VK_DECIMAL VK_SEPARATOR is in there, but VK_DECIMAL is missing. Adding it does the right thing on my keyboard.
Oddly enough, *without* this patch, when I type the keypad decimal key, I get a comma (which *is* the correct decimal sign in my locale). With this patch, I get a point. This is in a GTK+ text entry field. In testgtk's spinbutton test, without this patch, the keypad decimal key works and inputs a comma. With this patch, nothing happens when I type it. I am confused... Jody, when you say "the right thing", I assume you mean in a locale where the decimal separator is a point, and the key is labeled with a point?
Can anybody confirm (or disagree with) what I say in the previous comment?
Created attachment 129484 [details] keypad decimal key in the goel seek tool Hi everybody, I use the gnumeric-1.9.4-20090205-debug win32 version from jody. On every cell or GTK text widget, when I press the keypad decimal key, I obtain a "," wich is correct for my locale. But I noticed that it doesn't work in the Goal Seek Tool, I still have a "." when I expect a "," from the keypad (cf.attachment).
The Goal Seek Tool use pure GtkEntry widgets for which KP_DECIMAL seems to be translated to '.' at least in french locale, on *nix as well as win32, AFAIK.
Jody, Jean, Olivir, could anybody comment on Tors question in comment 11? TIA!
Not sure what Jody meant, but what is certain is that in French locale, without patching gtk+, the decimal separator key from the numpad returns code 46, not KP_DECIMAL on win32. So, in a locale where the decimal separator is a comma, you can't use that key when typing decimal numbers. Quite strange that Tor sees exactly the inverse behavior.
Hm. Reopening as per last comment.
No piece of news about resolving this annoying bug on win32 ?
(Trying to undo clearly-intended changes to product, etc.)
This should be fixed in master by https://git.gnome.org/browse/gtk+/commit/?id=578043f97e891e423648c9f70ddf1d185f4615c4 and gtk 2.x by https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=cb3eb7cd777b6cea239898efde3239c39144a955
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new