Skip to content

Drag-and-drop file transfer has no progress feedback #3559

Open

Description

@tengshan2008

Drag-and-drop file transfer has no progress feedback

Summary

Dragging files between widgets (local preview → remote preview, remote → local, or between
directories) works, but it is completely silent while it happens. There is no progress
indicator, no percentage, no byte counter, no completion notification, and nothing in the UI
that tells me a transfer is still running versus already finished versus never started at all.

The practical effect is that I cannot tell a working transfer from a failed one. If I drop a
large file and the UI gives me no feedback, I have no way to know whether to wait, retry, or
go check with ls. So the most reliable workflow ends up being "drop it, then switch to a
terminal and verify" — which defeats the point of dragging in the first place.

Wave Version

0.14.5

OS

macOS 26.2 (arm64)

Steps to reproduce

  1. Open a local preview widget and a remote preview widget (e.g. via an SSH connection) side
    by side.
  2. Drag one or more files from the local preview into the remote preview directory.
  3. Observe: the drop completes, and eventually the file appears in the destination listing.
    During the transfer there is no progress indicator, percentage, throughput, or ETA —
    nothing at all.
  4. Drag a large file (hundreds of MB, or a big video/archive) and repeat step 3. The wait can
    be long enough that it is indistinguishable from the drag having been ignored.
  5. Try the same drag over a connection with poor bandwidth. There is still no feedback, and no
    error or failure indication if the transfer does not complete.

Expected behavior

Some visible indication that a transfer is in flight and how far along it is. Concretely,
what I would hope for:

  • A progress indicator on the source and/or destination widget while the transfer runs —
    percentage, or bytes transferred / total bytes, plus throughput and ETA for large files
  • A visible drop-target highlight while dragging over a widget, so it is clear the widget will
    accept the drop at all (right now there is no hover affordance)
  • A clear completion state, and an explicit failure state if the transfer errors out
  • Transfers tracked per file, so dropping 10 files shows 10 distinguishable items rather than
    one ambiguous blob
  • Ideally the transfer should be non-blocking — I would want to keep working in other widgets
    while it runs, and come back to a finished (or failed) result

The reference point here is Xftp / any SFTP client: transfer list with live progress, and
background transfers that survive navigating away.

Actual behavior

The transfer runs with no feedback of any kind. Based on the docs and my own testing, the
file-view keybindings and drag-and-drop documentation describe the drag gesture itself but say
nothing about progress reporting, and I could not find a progress indicator anywhere in the UI.

Worth separating clearly: this is not a request to add drag-and-drop. That capability
already exists and works. #929 asks for dragging between directory preview blocks, #1685 asks
for Xftp-style drag-and-drop transfer, and #2044 asks for multi-select during upload. This
issue is only about the missing feedback on transfers that already run — it applies
equally to transfers that originate outside Wave (e.g. dragging in from Finder/Explorer), so it
is broader than just the widget-to-widget case.

Current workarounds

  • Switch to a terminal block and verify with ls -lh, du -sh, or df -h.
  • Use rsync/scp/cp in a terminal, where at least the shell reports progress, then refresh
    the preview with Alt+Shift+R.

Both work, but they mean the GUI drag gesture can never be trusted on its own.

Anything else?

My guess at the shape of the work: the transfer already exists as a backend operation, so this
is mostly a matter of surfacing per-file state (queued / in-progress / done / failed) into the
existing model and rendering it in the file widgets. That also seems like it would naturally
serve #929 and #1685, since a real transfer list is what makes those usable as an SFTP client.

Per CONTRIBUTING.md I understand larger changes should be discussed in Discord first — happy to
move this there if that is the better venue. I am also happy to dig into the code and propose a
concrete approach, either as an issue comment or a PR, if that would help.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions