Drag-and-drop file transfer has no progress feedback
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 25/100
Direzione di ricerca
Start with the existing backend transfer operation that drag-and-drop calls, then trace how the file preview widgets receive its results; the issue names no specific files. Before writing code, check CONTRIBUTING.md, which asks for larger changes to be discussed on Discord, and align on the per-file state model with #929, #1685 and #2044. Done means per-file queued, in-progress, completed and failed states are visible in the widgets for transfers from inside and outside Wave.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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
- Open a local preview widget and a remote preview widget (e.g. via an SSH connection) side
by side. - Drag one or more files from the local preview into the remote preview directory.
- 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. - 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. - 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, ordf -h. - Use
rsync/scp/cpin a terminal, where at least the shell reports progress, then refresh
the preview withAlt+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.
- Lingua principale
- Go
- Stelle
- 22.7k
- Fork
- 1.2k
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di wavetermdev/waveterm
-
bug triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
wavetermdev/waveterm#3587 ·
I maintainer di solito rispondono entro 1 giorno
-
bug triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
wavetermdev/waveterm#3568 ·
I maintainer di solito rispondono entro 1 giorno
-
pwsh: encodeEnvVarsForPowerShell rejects Windows-standard env var names like ProgramFiles(x86), breaking wsh token on every pwsh blockForse già presa @vortsghost2025 l’ha presa 63 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
wavetermdev/waveterm#3481 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
wavetermdev/waveterm#3435 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
wavetermdev/waveterm#3432 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di wavetermdev/waveterm
Issue simili
-
area/installation kind/bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
vllm-project/aibrix#3456 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
go good first issue help wanted up-for-grabs
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
andrewsiah/agentswarm-data-tasks#236 ·
I maintainer di solito rispondono entro 1 giorno
-
kind/bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
cadence-workflow/cadence#8745 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 79/100
charmbracelet/crush#4271 ·
I maintainer di solito rispondono entro 1 giorno
-
Flake: TestTheTimerBeginsTheNextGame leaves restore-point writes running into TempDir cleanupApertabug in-progress needs-triage P1 tier:2-standard
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
krakenhavoc/cmd_and_ctrl#5693 ·
I maintainer di solito rispondono entro 1 giorno