Note: this should be implemented after #466
Status: discussion, not a firm request. This is a proposal to talk through
the UX before anyone writes code. Depends on the EC work in
"Expose live upload activity for shared files over EC" landing first — the
desktop GUI and amulegui consume the same EC tags, so there is nothing to show
until those tags exist.
Background
The Web UI Shared Files page and the desktop shared-files view
(CSharedFilesCtrl, src/SharedFilesCtrl.cpp; enum at :73, column setup at
:101-112) both display only static counters for a shared file. Neither can
show whether a file is actively being uploaded, how fast, to how many peers,
or when it was last active — the core does not expose that per file yet.
The companion EC issue adds those fields (upload speed, peers uploading now,
uploading/queued split, last-upload-activity and shared-since timestamps). Once
they are on the wire, CSharedFilesCtrl — used by both the standalone aMule GUI
and the remote amulegui — could surface them too, keeping the desktop and
web clients at parity.
Today's desktop columns for reference (SharedFilesCtrl.cpp:101-112): Name,
Size, Type, Priority, File ID, Requests, Accepted Requests, Transferred Data,
Share Ratio, Obtained Parts, Complete Sources, Directory Path.
Sketch of what could be added
New optional columns fed by the EC fields from issue 1:
- Upload speed — current per-file upload rate.
- Uploading / queued — active uploaders vs clients waiting on the queue.
- Status — a simple "Uploading" / "Idle" indicator derived from speed +
active-uploader count.
- Last active — last upload activity time.
- Shared since / completed — when the file became available.
Points to discuss before implementing
- Column clutter. The desktop list already has 12 columns. Which of the new
ones (if any) should be visible by default, and which off-by-default? Is a
single derived "Status" column preferable to several raw ones?
- Presentation of "status". Icon, coloured text, or a plain label? Should it
match however the Downloads/Transfers view already signals activity?
- Sorting & live refresh. Speed and status change constantly — confirm the
existing refresh/sort path in CSharedFilesCtrl handles frequently-changing
numeric columns without excessive redraws.
- amulegui vs standalone. Both share the control, but amulegui pays EC
round-trip cost. Are the new tags cheap enough to send on the regular shared
list update, or should any be detail-only (fetched on selection)?
- Consistency with the Web UI. Agree on column names / semantics so desktop
and web describe the same field the same way.
- Timestamps. Absolute vs relative ("2h ago") display, and behaviour for
files that have never been uploaded (empty vs "never").
Scope
Non-goal for the first pass: redesigning the shared-files view. The idea is to
reuse the existing CSharedFilesCtrl column mechanism and add a small, agreed
subset of the new fields — no new panels or dialogs unless discussion decides
they are worth it.
Note: this should be implemented after #466
Background
The Web UI Shared Files page and the desktop shared-files view
(
CSharedFilesCtrl,src/SharedFilesCtrl.cpp; enum at:73, column setup at:101-112) both display only static counters for a shared file. Neither canshow whether a file is actively being uploaded, how fast, to how many peers,
or when it was last active — the core does not expose that per file yet.
The companion EC issue adds those fields (upload speed, peers uploading now,
uploading/queued split, last-upload-activity and shared-since timestamps). Once
they are on the wire,
CSharedFilesCtrl— used by both the standalone aMule GUIand the remote amulegui — could surface them too, keeping the desktop and
web clients at parity.
Today's desktop columns for reference (
SharedFilesCtrl.cpp:101-112): Name,Size, Type, Priority, File ID, Requests, Accepted Requests, Transferred Data,
Share Ratio, Obtained Parts, Complete Sources, Directory Path.
Sketch of what could be added
New optional columns fed by the EC fields from issue 1:
active-uploader count.
Points to discuss before implementing
ones (if any) should be visible by default, and which off-by-default? Is a
single derived "Status" column preferable to several raw ones?
match however the Downloads/Transfers view already signals activity?
existing refresh/sort path in
CSharedFilesCtrlhandles frequently-changingnumeric columns without excessive redraws.
round-trip cost. Are the new tags cheap enough to send on the regular shared
list update, or should any be detail-only (fetched on selection)?
and web describe the same field the same way.
files that have never been uploaded (empty vs "never").
Scope
Non-goal for the first pass: redesigning the shared-files view. The idea is to
reuse the existing
CSharedFilesCtrlcolumn mechanism and add a small, agreedsubset of the new fields — no new panels or dialogs unless discussion decides
they are worth it.