Created attachment 154288 [details] Overdue show in red example SUMMARY When loading the Schedule Transactions page my transaction all show in white regardless if the are past due or not. I attached two screenshots to show the issue. The one with items in red is from 5.1.2-6ff757b the other screenshot where all in white is from Release build 320 (https://binary-factory.kde.org/job/KMyMoney_Release_appimage-centos7/320/artifact/kmymoney-5.1-320-linux-gcc-x86_64.AppImage) 5.1-3-71876c371 OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Created attachment 154289 [details] Overdue transactions are in white Added screenshot
Forgot to fill in the other sections OBSERVED RESULT Overdue Scheduled transactions are white EXPECTED RESULT Overdue Scheduled transactions should be red SOFTWARE/OS VERSIONS Linux/KDE Plasma: Ubuntu 20.04 KDE Plasma Version: 5.18.8 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 ADDITIONAL INFORMATION Kernel 5.15.0-48-generic
Any update on this?
(In reply to Eleazar from comment #3) > Any update on this? Still present as of App image 420 (Version 5.1.3-fb2f0d78f)
I scanned the source multiple times now and cannot figure any cause for this. Also, I cannot reproduce the problem :( 1. Are you comparing the two versions on the same computer? 2. With KMyMoney not running, can you rename ~/.config/kmymoney/kmymoneyrc to some other name? Then check if the problem persists. The file will be re-created but you can override it with your original after the test to get back your settings (again, do this without KMyMoney running). 3. Does the problem also show up in the current master version?
(In reply to Thomas Baumgart from comment #5) > I scanned the source multiple times now and cannot figure any cause for > this. Also, I cannot reproduce the problem :( > > 1. Are you comparing the two versions on the same computer? Yes. Comparison made on same machine (back to back comparison) > 2. With KMyMoney not running, can you rename ~/.config/kmymoney/kmymoneyrc > to some other name? Then check if the problem persists. The file will be > re-created but you can override it with your original after the test to get > back your settings (again, do this without KMyMoney running). I renamed the file and opened my kmy file and the issue is still present > 3. Does the problem also show up in the current master version? I haven't tried to build it from source cause I had issues last time I tried (hence why I am using AppImages)
Updated on box specs Linux/KDE Plasma: Ubuntu 22.04 KDE Plasma Version: 5.24.7 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION Kernel 5.19.0-35-generic Graphics Platform: X11
> .... (hence why I am using AppImages) I duplicated it using the latest AppImage of the stable branch. So we now have the following scenario: KMyMoney Build as Version Native App AppImage 5.1.2 OK OK 5.1.3 OK FAIL master OK OK Since the code that causes the overdue entries to be shown in red is 100% identical between 5.1.2 and 5.1.3, I suspect the cause to be something related to the theme used in AppImages. The master version uses a completely different code base and therefore might not have the problem. Even though it is annoying for some of you, I would call it a corner case caused by an external piece of software which we have no control over. And since it works with the latest master version, there is a fix in sight. I am tempted to close it as a DOWNSTREAM or UNMAINTAINED problem but put it into WAITINGFORINFO for the moment.
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!
Reopening since the waiting for info triggered to auto close and it's still present in latest (505013)
Changing back to Waiting for Info
Waiting for Info will always get auto-closed in 30 days. The question is probably what status to use when closing. Thomas had suggested UNMAINTAINED, which I think is inappropriate for the currently supported version. DOWNSTREAM is possibly reasonable, as the cause is likely tied into the Appimage packaging, but in a way we don't control, or at least don't understand. Unless someone can figure out how to make the Appimage build work, this will not get fixed in any 5.1 version. I prefer to close it as fixed in 5.2, which is the version we are using for things fixed in master branch. There is still no proposed schedule for that to happen, but it will be at least several months.
Since the changes in master resolve the problem both in self compiled and appimage versions, I'm changing status, as WORKSFORME implies we couldn't replicate, which is not the case.