GNOME Bugzilla – Bug 80139
pressing KP_Decimal should input the right thing
Last modified: 2005-11-13 07:35:32 UTC
When I press KP_Decimal (decimal separator on the keypad), I always get a full stop ".". However, when I use Swedish locale, the decimal separator is a comma ",", and so the input doesn't match. I find this annoying, Gnumeric should know about KP_Decimal and always input the right character (given by the locale), so that it's always possible to input decimal numbers with the keypad.
Shouldn't the keyboard mapping take care of this?
The keyboard mapping just says that a certain key should be KP_Decimal or not, it doesn't say what actual character should be emitted when that key is pressed. That's up to the application to decide. The application normally calls something like XLookupString and gets a string from the X server. In this case, however, "KP_Decimal" (as opposed to "period" or "comma") is returned, and any application which has special handling of decimal numbers should really treat it as the decimal separator, no matter what the decimal separator is.
Let me say "me too" :) However, I think it should be turn-on/off-able option at an application (Gnumeric) level for I can imagine someone would like to input some data using the other separator character. Polish locale also uses comma as a decimal point but I type quite often IP addressess and hate it when the numeric keypad forces the comma.
*** Bug 321282 has been marked as a duplicate of this bug. ***
Proposed patch over in bug 321282. http://bugzilla.gnome.org/attachment.cgi?id=54667&action=view
Patch needs a little work, IMHO. format_get_decimal returns a GString* and the length is thus known. There is no need for the src/widgets/gnumeric-expr-entry.c patch to call strlen on that.
Created attachment 54673 [details] [review] updated patch.
I wrote something similar but somewhat simpler. However, I am not happy with the result. It only handle ExprEntry and the canvas. It doesn't handle other entries or spin buttons. We had what we wanted for a while in gtk itself but it was reverted. An ideal solution would be something like a gdk_window_add_filter but at the keyevent layer. For now I think we're stuck with something cheesy. Your approach of manually handling the strings seems somewhat more robust than my approach of just mapping the keyvals. Please scale your patch to handle KP_Separator and commit tommorow for 1.6.1.
My solution does not handle other entries or spin buttons either. KP_SEPARATOR is a synonym of KP_DECIMAL?