feat(board): fade dragged card immediately and fix stale drag state#3524
Merged
Conversation
Move the click-vs-drag decision to release time: any motion while a card is pressed immediately marks it as dragging (and fades its colors), while dropping back on the same card is still treated as a plain click so double-click-to-attach keeps working. Assisted-By: Claude
aheritier
added
area/tui
docker-agent
reviewed
Jul 8, 2026
docker-agent
left a comment
docker-agent
left a comment
Contributor
There was a problem hiding this comment.
Assessment: 🟢 APPROVE
The drag-fade implementation is well-structured. The visual feedback helpers in view.go correctly blend card colors toward the background using explicit foreground values that are always set. The click-vs-drag decision at release time is logically sound — bubbletea's single-threaded update loop means there is no race between cardAt bounds-checking and the card-ID lookup on the same line. The wheel-suppression guard (dragCardID != "") is intentional per the PR description and avoids accidental column scrolls during a card press. No bugs found in the introduced changes.
Sayt-0
approved these changes
Jul 8, 2026
Reset drag on attachReadyMsg and defensively in handleClick so a lost mouse release cannot silently move a card. Ignore wheel events while a card is pressed to avoid shifting selection mid-drag. Assisted-By: docker-agent/claude-sonnet-4-5
dgageot
force-pushed
the
worktree-board-f7252aa0ba2f84be
branch
from
July 8, 2026 08:55
3a9a229 to
b551867
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When dragging a card on the board, there was no visual feedback during the drag itself — the card looked identical whether it was being moved or stationary, making it hard to tell that a drag was in progress. Additionally, the drag only started after the pointer had moved outside the card's bounds, which felt sluggish and meant a fast move could pick up the wrong card.
The card now begins fading toward the theme background on the first mouse motion while the button is pressed, not when the pointer crosses a boundary. New helpers in
pkg/board/tui/view.goblend the card's title, project badge, status line, and border color toward the background, giving a clear "lifted" appearance. The click-vs-drag decision moved to release time: releasing the button over the card that was originally pressed counts as a plain click (so double-click-to-attach still works), while releasing anywhere else finalizes the move.A follow-up fix resets drag state that was lost when
tea.ExecProcess(the attach flow) consumed the mouse-release event, preventing a later plain click from silently moving a card. Wheel events are also ignored while a card is held down to avoid accidental column scrolls mid-drag.