Sorry made a mistake on steps to reproduce, should be :
2. The actual number doesn't contain dot or comma separator

Are you sure that your KDE locale settings have comma as the "Decimal Separator"? I just tried setting my locale to France and it appeared to work fine.

Oh wait, you are trying to use a "." character? Well the locale for french says that comma (",") is the Decimal Separator, so that is what should be used.

Thanks Evan for investigating this problem.

In fact on my French keyboard the numeric keypad holds a "." (dot) key between 0 and Enter (Entrée in French)

In previous KDE versions (including 4.9.5) this key produces a decimal separator (which is ',' = comma in French). I think it's how it is intended.
I understand that it is weird since the key has a dot on it and produces a comma when pressed but it's how I was always used to for years so I didn't even see this "inconsistency".

It actually works using the comma key on main keyboard but is completely painful to type many operations on many decimal numbers...
I suppose the meaning of this key is more 'decimal separator' than precisely dot or comma...

Hmm, I will have to investigate if that key can be detected independently from an ordinary "." character. I tightened up the code that parses numbers to be precise about what it accepts.

I can't test it now on my laptop (no keypad), but I think we can special case when Qt::Key_0 is pressed with the Qt::KeypadModifier flag. In which case, I will have it inject the correct delimiter into kcalc.

This is possibly what I experience in Greek, too: when the keyboard is set to the English layout, the . key on the numeric keypad produces a . but when the keyboard is set to the Greek layout, the same key produces a , -- which is correct since the decimal symbol in Greek is the comma.

But I am almost sure that in KDE prior to 4.10, pressing that key resulted in the decimal symbol being entered in kcalk regardless of the layout used. So probably kcalc could be made to detect when that *key* is pressed and enter the decimal symbol.

Yes, this is a regression in functionality. Looking at the old code, previous versions of kcalc basically just considered both the "," and "." keys as decimal separators.

The new version of kcalc specifically uses the locale's separator. I have added code for the next release which special cases the "." key on the number pad. I believe this should resolve the problem.

*** Bug 315234 has been marked as a duplicate of this bug. ***

*** Bug 315533 has been marked as a duplicate of this bug. ***

> have added code for the next release

Did you push this change yet?

it should be pushed to both master and the 4.10 branches. Gonna call it resolved cause the fix is in git.

This bug is not fixed in KCalc from KDE 4.10.1.

I have just tested a few minutes ago and it's OK for me on 4.10.1 on Slackware64.
It works on my kcalc 2.13 / kde 4.10.1

I have tested with Arch Linux 64 bits packages.
I will test with Fedora (kde-unstable) packages soon.

The bug is fixed in KCalc.

There is a bug with the "fr oss" keyboard layout which does not interpret keypad decimal key as KP_Decimal :

"fr" layout, xev result (it works in KCalc) :

KeyRelease event, serial 40, synthetic NO, window 0x6e00001,
    root 0xbf, subw 0x0, time 2127974, (731,660), root:(731,681),
    state 0x10, keycode 91 (keysym 0xffae, KP_Decimal), same_screen YES,
    XKeysymToKeycode returns keycode: 129
    XLookupString gives 1 bytes: (2e) "."
    XFilterEvent returns: False

"fr oss" layout, xev result (it does no work in KCalc :

KeyRelease event, serial 40, synthetic NO, window 0x6e00001,
    root 0xbf, subw 0x0, time 2150342, (972,547), root:(972,568),
    state 0x10, keycode 91 (keysym 0x2e, period), same_screen YES,
    XKeysymToKeycode returns keycode: 59
    XLookupString gives 1 bytes: (2e) "."
    XFilterEvent returns: False

I have added a line in my Xorg configuration (legacy dot for keypad):
    Option          "XkbOptions" "kpdl:dot"

Now, I have a dot in most applications (kate, konsole) and comma in KCalc and LibreOffice Calc.

Thank you for the bug fix.

It doesn't work on Kubuntu with KDE 4.10.1 / Kcalc 2.13 from ppa depot

@Maxime Chassagneux,

Are you using a french keyboard/locale? If so, please see the xorg fix that Damien Gombault posted above, it seems to be the easiest fix.

@Evan Teran

Yes I use a french keyboard ( i.e fr(oss) ) and yes the Damien Gamboult fix works for me too. (thanks to him by the way)
But I really don't think that this solution is THE solution. Ask to french people to modify their xorg's settings isn't the good approch no ? 
I don't known exactly how Kcalc work, but handle  « period », « comma », « KP_Decimal » and « KP_Separator » as decimal separator in the code is for me much better.

Glad that you have a solution :-).

The previous version of kcalc simply treated both comma and period as the decimal separator. I believe this to be a flawed solution. So the current solution is to actually use the locale's decimal separation character.

In 4.10.1, I added an addition to this. Where if the user hits the period character AND it is on the keypad then it is decided that a decimal separator is to be inserted.

Specifically, I look for Qt::Key_Period with Qt::KeypadModifier set.

It seems that the issue is that without the "kpdl:dot" option, X windows does not appear to report things as specifically as we would want.

Unfortunately, I don't have a french keyboard to do more tests with. If I sent you a quick test program would you compile and run it and report the results? I'd like to find out how Qt reports they keypress (with and without the "kpdl:dot" option) so we can find the ideal solution.

(In reply to comment #20)
> The previous version of kcalc simply treated both comma and period as the
> decimal separator. I believe this to be a flawed solution. So the current
> solution is to actually use the locale's decimal separation character.

IMHO, the previous behavior was correct too and, most importantly, more practical. KCalc does not have different functions for the period and comma, so it doesn't really need to make a distinction. There's no ambiguity. Also, since KCalc is modeled like an actual calculator, it might be best to behave like one. I owned many calculators, and none of them used a comma. KCalc feels weird compared to real calculators.

@Nickos Chantzlaras: I've never used a real calculator which used a comma either :-P.  I assume you are from a locale which uses a comma for decimal notation though right? If so, on your calculator, when you pressed period, what did it display? I comma or a period?

I'm not sure in what way kcalc does not behave like a real calculator. Are you saying that in France, even though the local convention is to use a comma to as a decimal separator, hand held calculators use a period instead? I would find that very odd (and at the very least, confusing for students).

I ask, because you say that kcalc "feels weird", I am simply trying to emulate what I believe to normal for each given locale. So the more information the better.

Of course I can campile and test a program for you.

Maxime Chassagneux ,

Thanks! I really think this will help get to the bottom of the issue and find an ideal solution. I will attach a tarball called keyboard_test.tgz, you can run it with the following steps:

$ tar xfz keyboard_test.tgz
$ cd keyboard_test
$ qmake
$ make
$ ./keyboard_test

It will open a window, which when you press a key will display some information which will look something like this (numbers change depending on which key is pressed).

KEYPRESS: 01000007 [20000000]

If you could report the results of the following:

comma pressed
period pressed
period pressed on number pad (with numlock)
period pressed on number pad (without numlock)

please run both with and without the "kpdl:dot" xorg option. This will allow me to know how your keyboard is reporting these events and how I can best interpret them properly.

Thanks again!
Evan

Created attachment 78073 [details]
Keyboard Test Application

to compile and run:

$ tar xfz keyboard_test.tgz
$ cd keyboard_test
$ qmake
$ make
$ ./keyboard_test

Voila :

Without "kpdl:dot"

comma : KEY PRESS: 0000002c [00000000]
period : KEY PRESS: 0000002e [02000000]
period pressed on number pad (with numlock) : KEY PRESS: 0000002e [00000000]
period pressed on number pad (without numlock) : KEY PRESS: 01000007 [20000000]

Without "kpdl:dot"

comma : KEY PRESS: 0000002c [00000000]
period : KEY PRESS: 0000002e [02000000]
period pressed on number pad (with numlock) (i.e KP_Decimal ) : KEY PRESS: 0000002e [20000000]
period pressed on number pad (without numlock) : KEY PRESS: 01000007 [20000000]

Sorry I've made a mistake, the second part of the test is with "kpdl:dot" option.

OK, well based on this, I am inclined to believe that the "kpdl:dot" option the "correct" setup. The reason I say this is because the keyboard appears to report the wrong information without it!

The first number is the scancode, the number inside the brackets represent the flags associated with a given keypress, in this case "[20000000]" means "the button was on the keypad".

As you can see, the second set (with "kpld:dot") correctly reports that the key pressed was a period (scancode 0x2e) and has the "keypad flag" set. Without the kpld:dot" option, the flags are reversed.

My assessment is that originally the xorg people got it reversed, and chose to fix it by adding a new flag. They seem to be retaining backwards compatibility by default. Personally, I would have made it default to correct behavior and had the flag provide the backwards compatible results. But oh well.

Additionally, interestingly enough, it seems that the "new behavior" is to always report that the period button is from the keypad. That shouldn't harm anything though.

Thanks for the information, it was very helpful. I will look into what the ideal solution is. I certainly agree that things should "just work". But it does seem that xorg is reporting the wrong information by default.

Thanks!
Evan