Version: .09 (using KDE 3.5.10) OS: Other Installed from: Ubuntu Packages Gentlemen: I like this program and I'm beginning to think of dumping Quicken in favor of KmyMoney. But before I do that I would like to see the following: 1. User must be able to enter a negative amount directly in the Split window without using the calculator. I find this rather cumbersome and it slows me down. 2. Once you're done entering a transaction, the program should set the focus on the "payee" field. The user then won't have to click on "New" everytime. 3. There should be a drop-down list of payment types that the user can modify. The list might include types such as Debit, Credit, TRF, EFT, etc. The selection should default to a number (check) if the user does not make a selection. 4. The reports should include or allow to be included a column that will show percentages of income or expenses. Also, it should give the option to include a column for prior period's (year or month) data. 5. In the split window, the cursor should automatically set focus on the first field and by pressing tab, it moves to the next field and records or accepts the value in the immediately preceding field without clicking the green arrow button. I don't see a need for the red X button. 6. And last but not the least, I would like to see Sounds being added when you perform certain actions such as "Enter" of "Delete". It would greatly enhance your program, and I believe a lot of people would love it. Thanks a lot and keep up the good work. Pete
Pete, a few quick answers: 1) this has been fixed in later versions. Please upgrade to 0.9.3 2) As a workaround: the keyboard shortcut Ctrl-Ins should do the trick. 5) Has also been enhanced in 0.9.3 such that pressing Enter will do what you look for. Requires the option 'Use Enter to move between fields' to be turned on in the settings dialog. 6) Do you have some nice sounds that are covered by a free license? I know, that some commercial apps have such a feature and it is not too hard to add either. Having the sound files is our problem here.
Moving this wish to kmymoney4.
So much has changed since 0.9 and even 4.8. It would be good to revise, or at least confirm, the list to show what is still missing from 5.1.1.
(In reply to Jack from comment #3) > So much has changed since 0.9 and even 4.8. It would be good to revise, or > at least confirm, the list to show what is still missing from 5.1.1. There is a list for this purpose, see https://bugs.kde.org/buglist.cgi?cmdtype=runnamed&list_id=1840437&namedcmd=version_5_relevant. It uses the ticket flag 'Version_5'.
The link Ralf provided produces "The search named version_5_relevant does not exist." for me. Maybe it is private to the user logged in.
(In reply to Thomas Baumgart from comment #5) > The link Ralf provided produces "The search named version_5_relevant does > not exist." for me. Maybe it is private to the user logged in. I changed the access group from "contributor" to "canconfirm", which is the value most often used - can you please take a look into Preferences->Saved Searches after log into bugs.kde.org and see if it is listed there ?
(In reply to Ralf Habacker from comment #6) > I changed the access group from "contributor" to "canconfirm", which is the > value most often used - can you please take a look into Preferences->Saved > Searches after log into bugs.kde.org and see if it is listed there ? Works for me.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
I have had this #1 bug for ages. I remember that it used to work, but then it went broke, and haven't been fixed since. To repeat: 1. Create new transaction. 2. Go to split dialog. 3. Enter new split, use negative amount. => Amount is automatically converted positive, unless one re-edits the field and adds negative sign.
What version are you using? I have no problem entering a negative number for the value in the split editor. (Aside from the question of entering negative values, do we want to create new wishlist items for the other requests in the original post which are not yet done?)
Jack kirjoitti 20.3.2021 19:15: > What version are you using? I have no problem entering a negative > number for > the value in the split editor. > (Aside from the question of entering negative values, do we want to > create new > wishlist items for the other requests in the original post which are > not yet > done?) I'm using currently 5.1.1, but this issue has been bugging me 5-10 years now, so it applies multiple versions prior. I remember reporting it back then, but apparently it didn't get fixed. If you don't have the issue, could this be related locale settings etc.?
That's an interesting thought. I'm using 5.1 compiled from git head, although I don't know of anything that has changed recently that should affect this. I'm using en-US.UTF-8 and US Dollars for currency. Can you try creating a new sample kmy file and test with the settings you currently use, and then with mine?
Jack kirjoitti 20.3.2021 21:45: > That's an interesting thought. I'm using 5.1 compiled from git head, > although > I don't know of anything that has changed recently that should affect > this. > I'm using en-US.UTF-8 and US Dollars for currency. Can you try > creating a new > sample kmy file and test with the settings you currently use, and then > with > mine? Okay, I did that, and some other extra testing. Here are my observations: - When using Finnish locale settings, I cannot input minus sign at all, neither in ledger or in split window dialog. Only way to do this, is input the amount first, and then edit it by adding the minus sign. - When using EN US settings with US dollars, I could input the minus sign into the amount field. But, effectively it was still discarded. If I entered new transaction with expense category, and used positive sum, the transaction decreased the account total as expected. But if I entered negative amount with expense category, the account total was still decreased. This is problematic because if one gets refund from expense category, it is too easy to enter it as expense because negative sign is discarded.
This definitely seems like a locale related issue. I created a new file (in a Ubuntu 18.04 as a VirtualBox guest) using a recent appimage. I set the locale to Finnish, created a new KMM file using the Finnish Markka as default currency. First, the problem is not specific to the split editor. Just entering a transaction in the ledger, when I get to the amount field, hitting the - key has no effect. If I type some digits first, hitting the - key brings up the calculator. If I click or use the arrow keys to put the entry position at the beginning of the number, hitting the - key does enter a "-" making the number negative. I don't know anything about Finnish - does a default display of a negative number put the "-" at the beginning or end? Is the "-" typically typed at the beginning or end of a string of digits? If the KDE locale handling is expecting the minus sign after the rest of the number, it will never get it, since KMM seems to treat a "-" anywhere except at the beginning of a number as a call for displaying the calculator. At this point, I don't know what else to test or try.
Can anyone describe how number entry is supposed to work in Finnish? I don't think we can refer this to the PLasma/locale team without more information, such as whether the problem occurs in any other application or any other locale.
Sorry, I forgot to comment on this. There is no weird exceptions with Finnish locale. The negatives are displayed with dash at the beginning, space is used as a thousands separator, decimal separator is comma. Currency unit is euro ("markka" was before that). For example: - Negative amount: -15 523,55 € - Positive amount: 2 643,23 € At least here in Europe that should be pretty standard (with maybe exception of decimal sign, comma vs. dot).
Might there be something about the space as a thousands separator?
That sounds unlikely, since space is used also on French locale (fr_FR) as thousand separator, so you would have most likely already gotten multiple notifications about that. :)
KMyMoney gets locale information about the sign position and format from the locale and if that returns unexpected (undefined) values it causes the application to not except negative numbers because it does not know where to place the minus sign (or other notations).
Git commit 6298def0763c7cc00ebf5e036782544ea1ff95b6 by Thomas Baumgart. Committed on 18/04/2021 at 18:49. Pushed by tbaumgart into branch '5.1'. Use defaults if locale does not provide valid values In case invalid values are returned by localeconv() for the currencySignPosition and the currencySymbolPosition the default values will be used instead to avoid malfunction of the application. M +11 -0 kmymoney/misc/platformtools_gnu.cpp M +11 -0 kmymoney/misc/platformtools_nognu.cpp https://invent.kde.org/office/kmymoney/commit/6298def0763c7cc00ebf5e036782544ea1ff95b6
Git commit bb6c16612033a94ff4818b8c56b1b57158b53bd4 by Thomas Baumgart. Committed on 18/04/2021 at 18:46. Pushed by tbaumgart into branch '5.1'. Entering negative amounts switches between deposit and payment In some circumstances, entering negative amounts did not have any effect. This change fixes that so that entering a negative amount changes a payment into a deposit and vice versa. FIXED-IN: 5.1.2 M +6 -23 kmymoney/dialogs/stdtransactioneditor.cpp M +15 -0 kmymoney/widgets/kmymoneycashflowcombo.cpp M +1 -0 kmymoney/widgets/kmymoneycashflowcombo.h https://invent.kde.org/office/kmymoney/commit/bb6c16612033a94ff4818b8c56b1b57158b53bd4
Git commit 02749aa1e0e096a1f83b3fff8044a33883d7991c by Thomas Baumgart. Committed on 18/04/2021 at 18:52. Pushed by tbaumgart into branch 'master'. Use defaults if locale does not provide valid values In case invalid values are returned by localeconv() for the currencySignPosition and the currencySymbolPosition the default values will be used instead to avoid malfunction of the application. (cherry picked from commit 6298def0763c7cc00ebf5e036782544ea1ff95b6) M +11 -0 kmymoney/misc/platformtools_gnu.cpp M +11 -0 kmymoney/misc/platformtools_nognu.cpp https://invent.kde.org/office/kmymoney/commit/02749aa1e0e096a1f83b3fff8044a33883d7991c