SUMMARY When enter a scheduled payment and just do one single click on the up or down arrow of date picker, the day portion of the date runs up or down out of control. STEPS TO REPRODUCE (PATH A) 1. Go to "Home" on the left panel. 2. In the "Payments" area, click on the "Enter schedule" payment button of an existing scheduled payment. 3. Directly click on the up or down arrow button of the date picker to increase or decrease the existing date and wait for a couple of seconds. STEPS TO REPRODUCE (PATH B) 1. Go to "Schedule payments" on the left panel. 2. Right-click on any existing transaction and click on the "Edit scheduled transaction" option. 3. Directly click on the up or down arrow button of the date picker to increase or decrease the existing date and wait for a couple of seconds. OBSERVED RESULT The day component of the date picker runs up out of control until it reaches the end of the month. Conversely, if you clicked on the down arrow button, the day goes down out of control until it reaches the beginning of the month. EXPECTED RESULT It should go up or down one single day per click, unless you hold your click (long-press) on either the up or down arrow button. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 5.19.3 KDE Frameworks Version: 5.72.0 Qt Version: 5.15.0 ADDITIONAL INFORMATION Kernel version: 5.7.8-arch1-1
Have you confirmed this is specific to the date part of the date picker? Have you tried it on the year or month? Have you tried using any other date picker in another app? (Just trying to be sure if this is specific to one widget or more general.)
I also wonder if you have check mouse click behavior in any scroll-bar, just to be sure it's not an issue with your mouse buttons sticking. Not likely, but easy enough to rule out.
This is weird: the date picker object is used in other areas (e.g. transaction editor) where this problem does not show up. I analyzed it, and the problem is that the very first MouseReleaseButton event on the date picker after object creation is not reaching the object under unknown circumstances. This is not always, but the scenario you have reported shows it. I have no idea about the root cause, though. So it's not related to flaky hardware or the date picker in general.
Git commit fae59666c95c22ac68df3f347ba14c5e41a47f34 by Thomas Baumgart. Committed on 19/07/2020 at 09:21. Pushed by tbaumgart into branch '5.1'. Add missing release event in very specific case The date picker object is used in other areas of KMyMoney (e.g. transaction editor) where this problem does not show up. I analyzed it, and the problem is, that the very first MouseReleaseButton event on the date picker after object creation is not reaching the object under unknown circumstances in the enter schedule dialog. This is not always, but the scenario reported in the bug entry shows it. I have no idea about the root cause, though. Detecting the specific scenario and sending a mouse release button event based on the data of the press event solves the problem. Drawback: pressing the mouse long in that scenario now has no effect. It needs a second press to get the number increasing while the mouse button is pressed. FIXED-IN: 5.1.1 M +26 -0 kmymoney/widgets/kmymoneydateinput.cpp M +5 -0 kmymoney/widgets/kmymoneydateinput.h https://invent.kde.org/office/kmymoney/commit/fae59666c95c22ac68df3f347ba14c5e41a47f34
Git commit 2731fc0e2237d295e80d54e026c44b10110a287a by Thomas Baumgart. Committed on 19/07/2020 at 11:05. Pushed by tbaumgart into branch 'master'. Add missing release event in very specific case The date picker object is used in other areas of KMyMoney (e.g. transaction editor) where this problem does not show up. I analyzed it, and the problem is, that the very first MouseReleaseButton event on the date picker after object creation is not reaching the object under unknown circumstances in the enter schedule dialog. This is not always, but the scenario reported in the bug entry shows it. I have no idea about the root cause, though. Detecting the specific scenario and sending a mouse release button event based on the data of the press event solves the problem. Drawback: pressing the mouse long in that scenario now has no effect. It needs a second press to get the number increasing while the mouse button is pressed. (cherry picked from commit fae59666c95c22ac68df3f347ba14c5e41a47f34) M +26 -0 kmymoney/widgets/kmymoneydateinput.cpp M +5 -0 kmymoney/widgets/kmymoneydateinput.h https://invent.kde.org/office/kmymoney/commit/2731fc0e2237d295e80d54e026c44b10110a287a
*** Bug 403335 has been marked as a duplicate of this bug. ***
*** Bug 430630 has been marked as a duplicate of this bug. ***