| Summary: | kmymoney doesn't accept dead keys in "Pay to" field | ||
|---|---|---|---|
| Product: | [Applications] kmymoney | Reporter: | tnemeth |
| Component: | ux-ui | Assignee: | KMyMoney Devel Mailing List <kmymoney-devel> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | ostroffjh |
| Priority: | NOR | ||
| Version First Reported In: | 5.1.3 | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
We need to figure out if this is really a KMyMoney problem, or something in one of the underlying Qt or KDE libraries. Can you try entering all those various combinations in spreadsheet cells in Calligra? Also, can you try copy/pasting those combinations from any other program (or perhaps even from the memo field) into the payee field? That might distinguish between keboard entry problem and a problem dealing the the accented character itself. (In reply to Jack from comment #1) > We need to figure out if this is really a KMyMoney problem, or something in > one of the underlying Qt or KDE libraries. Can you try entering all those > various combinations in spreadsheet cells in Calligra? These combination work well with kwrite, konsole, kmail, kfind (KDE) and SpeedCrunch (depends on Qt only). I do not have Calligra installed. > Also, can you try copy/pasting those combinations from any other program > (or perhaps even from the memo field) into the payee field? Copy/paste works perfectly ! All the mentioned characters could be input in the field. The "Pay to" field is the only one affected. I could correctly type the characters in the "Category", "Tag" and "Note" ("Memo" ?). > That might distinguish between > keboard entry problem and a problem dealing the the accented character > itself. Seems to be a keyboard entry problem specific to that field. Accented characters are not one. However it has worked before. Indeed I always input new payees through that field. That means that a some point in time I had the possibility to input those characters correctly (it has been several months since I noticed that behavior but I only took my keyboard to report it today as I'm in a frenzy of bug reporting during my holidays ;) ) Thomas. I can confirm a very similar problem when using the Compose key to enter special characters. Observation: * In all cases I type Compose Key followed by " followed by o (which should result in ö) * I can confirm that entering ö with Compose Key works if it's the first character. * I can also confirm that trying to enter ö as second character doesn't work. The result is "o. * Entering aaö results in aa"o I think I just found the pattern. If the list of possible completions is shown then entering ö fails. If no completions are shown (i.e. when entering the very first character or when no payee/payer matches what has been entered so far) then entering ö succeeds. I see the same problem for Tags. I don't see the problem for Category. I have never experienced this problem in any other KDE or Qt applications (or any non-Qt applications like Firefox, LibreOffice, etc.) and I'm using Compose for entering umlauts everywhere. (I should really debug this myself. It's been bothering me for a long time.) Might it have to do with the field being a combobox which is showing possible completions? I'm not familiar with that code, but can you enter an accented second character if there is NOT already a possible completion of what you are trying to enter? (In reply to Jack from comment #4) > I'm not familiar with that code, but can you enter an > accented second character if there is NOT already a possible completion of > what you are trying to enter? No. The examples I displayed in the report weren't matching any completion. Moreover, looking at the completions, they are not sorted in alphabetical order. A..Z + Accented caps (É for me since the only payees I have that begin with an accented letter are beginning with É). Should be A..EÉ...Z in this case. Sorting is a different problem. I tried a few things and it all comes down to what Ingo already reported: The compose key has no function when the popup window of the completer is visible. Pressing ESC closes the popup window and then the compose key works as expected. I checked KMail and that does not show the problem in the recipient address field. Did not follow up on which widgets KMail uses at this point. Sorting is locale aware in the master branch, so that is fixed. |
SUMMARY Kmymoney doesn't want me to type "ô" in the "Pay to" field. Nor any other letter using a dead key... But only when it's not the 1st letter. Typing « Ô », « Ï », « ô » and « ï » works perfectly when they are the 1st letter typed in the input field. But when they are typed in the middle of a word, the dead accent isn't taken into account and only « o » or « i » is inserted. However I can try to type « Öô » but not « Ôö » nor « Ôô ». « Ôî » works but not « Ôï ». Strange isn't it ? Whatever, I'd like to type « Côté » and have the auto-completion do its work for the rest of the payee :) This really isn't a translation bug but an ux/ui bug... STEPS TO REPRODUCE 1. Create a new transaction 2. Try and type Côté in the "Pay to" field OBSERVED RESULT Only "Coté" (without the ^ on the o) is printed. EXPECTED RESULT "Côté" should be there :) SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux 12 KDE Plasma Version: 5.27.11 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.13 Kernel Version: 6.10.3-amd64 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i7-7567U CPU @ 3.50GHz Memory: 31.2 Gio of RAM Graphics Processor: Mesa Intel® Iris® Plus Graphics 650 ADDITIONAL INFORMATION N/A