Created attachment 188575 [details] File transfer graph bug SUMMARY Minimizing the File Transfer Progress Graph and then expanding it again causes the graph to slant at an extreme angle instead of starting vertically as it did when the transfer first started STEPS TO REPRODUCE 1. Copy a large file anywhere so that the File Transfer Progress Graph is displayed 2. Minimize the graph 3. Expand the graph again OBSERVED RESULT The initial portion of the graph is incorrectly slanted an an incline EXPECTED RESULT The graph should start vertically as it did when the file transfer was initiated (minimizing and re-expanding the graph causes the bug) Operating System: Manjaro Linux KDE Plasma Version: 6.5.4 KDE Frameworks Version: 6.21.0 Qt Version: 6.10.1 Kernel Version: 6.18.4-1-MANJARO (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i5-4690K CPU @ 3.50GHz Memory: 16 GB of RAM (15.6 GB usable) Graphics Processor: NVIDIA GeForce GTX 970
kind reminder
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6963
Git commit cd8af6e1b222c2eba3af7c7dc5fa80670f466d52 by Méven Car. Committed on 28/09/2026 at 06:49. Pushed by meven into branch 'master'. applets/notifications: Work the speed chart out from the job's own record The chart collected its own readings, and it only exists once the job has a list entry. Whatever the copy did before that went unrecorded, so the line climbed out of the corner up to the first reading, showing an acceleration that never happened, and closing the popup threw the readings away. Have the job note how far it has got and when, and work the chart out from that: two readings give the speed between them and where it belongs across the width. That draws the same for a job watched from the start, draws something true for one that was not, survives the popup closing, and works for a job that never says how fast it is going. The stretch before the first reading is drawn at how far the job had got by then over how long it had been going, level, rather than at whatever that one reading caught. A burst or a lull as we start watching says nothing about the time before it. Both are worked out when asked for rather than as readings arrive, because the total moves. A copy does not know how much it is about to copy until it has finished looking, and KIO revises it again for a single file whose size only the transfer knows. Readings placed against a width that no longer holds would be stranded; readings kept as taken are simply placed again, within the width of the chart, since a job may claim a total it then exceeds. Related: bug 519652 M +105 -85 applets/notifications/components/SpeedChart.qml M +65 -0 libnotificationmanager/job.cpp M +8 -0 libnotificationmanager/job.h M +36 -4 libnotificationmanager/job_p.cpp M +13 -0 libnotificationmanager/job_p.h https://invent.kde.org/plasma/plasma-workspace/-/commit/cd8af6e1b222c2eba3af7c7dc5fa80670f466d52