Bug 424402 - When entering a check/account statement number using the numeric keypad, insert '.' instead of ','
Summary: When entering a check/account statement number using the numeric keypad, inse...
Status: RESOLVED FIXED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: 4.8.4
Platform: Other All
: NOR normal
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-19 10:38 UTC by Ralf Habacker
Modified: 2020-08-31 14:09 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.8.5


Attachments
Numeric keypad delete behavior (53.87 KB, image/png)
2020-08-20 07:21 UTC, Thomas Baumgart
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Habacker 2020-07-19 10:38:27 UTC
SUMMARY
When entering bank statements several times using the keyboard, using the numeric keypad helps to save time during input. Unfortunately, when entering a bank statement number, e.g. 20.1 for a 20-sheet 1 statement, you will be slowed down because there is no '.' on the numerical block and you have to use the normal keyboard.

It would therefore be helpful if a '.' were inserted when entering a statement number via the ',' key on the numeric keypad.

STEPS TO REPRODUCE
1. start kmymoney
2. open a kmymoney file
3. enter a new transaction
4. enter the number field and try to enter '20.1' by using the numeric keypad.

OBSERVED RESULT
Entering a '.' is not possible using the numeric keypad.

EXPECTED RESULT
Entering a '.' should be possible using the numeric keypad.

SOFTWARE/OS VERSIONS
Windows: 10

ADDITIONAL INFORMATION
Account statement numbers can also be entered via the input dialog for planned bookings, which would also have to be adapted.
Comment 1 Jack 2020-07-19 13:53:29 UTC
That might depend on the keyboard.  I have a US generic 105 key version (that's from memory, so the detail may be wrong) and my keypad does have a '.' (dot).  I wonder if this is something deeper in the keyboard driver, using that character as the decimal separator, regardless of what's printed on the key.

In your case, if the keypad ',' were to insert a '.', wouldn't that mean you can't input the decimal separator from the keypad?  (That assumes your decimal separator is a comma.)

Or, are you saying what gets entered is context specific, depending on the field being entered?
Comment 2 Thomas Baumgart 2020-07-19 14:31:11 UTC
You may want to take a look at bug 423509 which is related. This bug entry is against the KDE4 version of KMyMoney. For KF5 based version there is an option in the keyboard handling that allows to have the numeric keypad dot being a dot no matter what the locale assignment is. That was the feature the original poster of bug 423509 had turned on and ran into problems entering numeric amount data.
Comment 3 juantxorena 2020-08-16 20:11:40 UTC
I can confirm this bug. I'm using fedora, it appeared after updating to version 5.1.0-1, previous working version was 5.0.8-2
Comment 4 Thomas Baumgart 2020-08-20 07:21:18 UTC
Created attachment 131033 [details]
Numeric keypad delete behavior

The numeric keypad delete button has a different meaning in different locales. No mentioning of locales here, so it is hard to give advice. For KF5 (don't know about KDE4) please take a look at the advanced keyboard settings (see attachment) and report back if any of that solves your problem or provide more details.
Comment 5 Thomas Baumgart 2020-08-20 07:21:33 UTC
Update state
Comment 6 juantxorena 2020-08-20 18:43:13 UTC
I have tried all the advanced options and nothing fixes it without breaking everything else.

Since you asked about locales, in a console I have the following:

$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

$ env | grep -e "LANG\|LC_"
LANGUAGE=
LANG=en_US.UTF-8

I have this values in both plasma and on tty. In KDE settings, the format is set as "Germany - English (en_DE)". Bug 423995 may be relevant.
Comment 7 juantxorena 2020-08-30 16:17:26 UTC
Is more info needed for fixing this?
Comment 8 Ralf Habacker 2020-08-30 22:01:32 UTC
(In reply to Thomas Baumgart from comment #2)
> You may want to take a look at bug 423509 which is related. 

Thanks for this guide, which gave me a hint in the right direction. I added a related fix to my personal 4.8-staging branch (see 
https://github.com/rhabacker/kmymoney/commit/db304ae5b7b2e1d2196529d646486b97073e8e8e), which works as expected. After some testing it will go into the 4.8 branch. I cannot say if it will work also with the 5.1 branch, but it could probably be used as a starting point.
Comment 9 Thomas Baumgart 2020-08-31 08:37:11 UTC
In the 5.1 branch this is fixed with https://invent.kde.org/office/kmymoney/-/commit/2e0440ec0d2d09475b4c09af4fd6cb6a6ccd3a1a. No need to add anything else.
Comment 10 Ralf Habacker 2020-08-31 14:09:56 UTC
Git commit 7d1b4331b3db2aebe7dd6db4171173279a07e719 by Ralf Habacker.
Committed on 31/08/2020 at 14:09.
Pushed by habacker into branch '4.8'.

Add support to get period on pressing comma at num key pad
FIXED-IN:4.8.5

M  +12   -1    kmymoney/dialogs/transactioneditor.cpp

https://invent.kde.org/office/kmymoney/commit/7d1b4331b3db2aebe7dd6db4171173279a07e719