https://bugs.kde.org/show_bug.cgi?id=514677

Méven <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
      Latest Commit|                            |https://invent.kde.org/plas
                   |                            |ma/plasma-workspace/-/commi
                   |                            |t/cd8af6e1b222c2eba3af7c7dc
                   |                            |5fa80670f466d52
             Status|ASSIGNED                    |RESOLVED

--- Comment #3 from Méven <[email protected]> ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to