feat(tui): wire Gallery screen to GalleryStorage #107
No reviewers
Labels
No labels
area:agents
area:ai
area:config
area:dashboard
area:design
area:design-review
area:devtools
area:entities
area:gallery
area:generate
area:image
area:infra
area:meta
area:model-browser
area:navigation
area:presets
area:security
area:sessions
area:settings
area:sharing
area:test
area:ux
area:webhook
area:workdir
type:bug
type:chore
type:meta
type:user-story
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
charles/loom!107
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "tui/gallery-wire-88"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
GalleryStorageviaAppCtxfor loading, searching, sorting, favorite toggling, and deletionr); search (/) and sort (S) trigger reloads with proper filtering/ordering*) persists immediately viatoggle_favorite_batch; delete (ddchord /Deletekey) removes items viadelete_batchAppCtx.render_imagewhen a renderer is availableTest plan
cargo clippy -p loom-tui -- -D warningspassescargo test -p loom-tuipasses (120 tests, 7 new)/, type a query, press Enter — verify filtered resultsSmultiple times — verify sort order cycles and items reorder*on an item — verify favorite indicator togglesddon an item — verify deletion and reloadr— verify items refresh from storageCloses charles/loom#88
🤖 Generated with Claude Code
Review — PR #107: Gallery screen wired to GalleryStorage
Good integration. Lazy loading, search, sort, delete, favorite toggle, detail view with image rendering — all wired up.
Concern:
dddelete has no undoThe
ddchord deletes immediately from SQLite with no confirmation dialog and no undo. For a gallery app where images are the primary asset, this is risky. Consider either:ctx.app.send(AppAction::PushOverlay(OverlayKind::Confirm(...))))Concern:
toggle_favoriteholds mutex during DB writeThis is fine for a single toggle, but the lock is
std::sync::Mutexshared across screens. If another screen is doing a long DB operation (e.g. gallery list with many items), this could contend. Low risk in practice.Minor
render_detailcallsctx.render_image(...)which acquires the renderer mutex during the render pass. If the image decode is slow (first render of a large file), the frame will lag. Consider caching the decoded image or rendering asynchronously.self.items.len()— this is the filtered count after search, not total. Consider showing "N of M items" when a search filter is active.Spacetoggle +dddelete interaction: if items are multi-selected,dddeletes all selected items. This is the right behavior but not discoverable. The hint row should mention it.Good test coverage, including the
pending_dreset logic.15bb8ef0d7tobd2cb9315dbd2cb9315dtod920790594