[Enhancement]: Add "Advance on Tag"

ValleyGeek commented

2026-06-20 05:48:33 +00:00

Owner

Affected area

All Areas

Current behavior

When tagging an image a tag is added and the selection doesn't change.

Desired improvement

Add a new toggle button immediately to the right of the "Tag Filter" button labeled 'AoT' with a label of "Advance on Tag: Automatically moves to the next image when a tag is added" along with a setting to enable or disable this by default (defaulted to selected).

When the feature is enabled, each time a tag is added to an image:

Grid: the next image is selected
Image Viewer: The next image is navigated to
Duplicate Workbench:
- Advance to the next non-deleted image in the set
- If no images remain in the set or there are no non-deleted ones next, move to the next duplicate set

Make the toggle move between three options:

Disabled
- No auto advance
Tags & Delete
- Advances immediately after applying a tag, including DELETE
Delete Only
- Only auto advance when a DELETE tag is added

This feature should completely ignore DUPE tags

References

No response

### Affected area All Areas ### Current behavior When tagging an image a tag is added and the selection doesn't change. ### Desired improvement Add a new toggle button immediately to the right of the "Tag Filter" button labeled 'AoT' with a label of "Advance on Tag: Automatically moves to the next image when a tag is added" along with a setting to enable or disable this by default (defaulted to selected). When the feature is enabled, each time a tag is added to an image: - Grid: the next image is selected - Image Viewer: The next image is navigated to - Duplicate Workbench: - Advance to the next non-deleted image in the set - If no images remain in the set or there are no non-deleted ones next, move to the next duplicate set Make the toggle move between three options: - Disabled - No auto advance - Tags & Delete - Advances immediately after applying a tag, including DELETE - Delete Only - Only auto advance when a DELETE tag is added This feature should completely ignore DUPE tags ### References _No response_

ValleyGeek added the

Priority

Low

Kind/Enhancement

labels

2026-06-20 05:48:33 +00:00

Claude referenced this issue from a commit

2026-06-20 16:47:40 +00:00

feat(tagging): Advance on Tag toggle across Grid, Viewer, and Dupes (#109)

Claude commented

2026-06-20 16:47:53 +00:00

Member

Implemented on branch 0.1.46/issue-109-advance-on-tag (chained off the previous dev branch, not merged to main yet — this is the last of the 10 chained groups covering all 19 open issues).

Added a new AoT toolbar button immediately to the right of Tag Filter that cycles through the three states you described: Disabled → Tags & Delete (default) → Delete Only. The mode is persisted (PREF_ADVANCE_ON_TAG_MODE) and restored on next launch, so the toggle itself doubles as "the setting to enable/disable by default" rather than needing a separate Settings-page control.

Behavior by area, gated on a tag/DELETE actually being added (never on removal), and always ignoring DUPE tags:

Grid: selects the next row.
Image Viewer: navigates to the next image.
Duplicate Workbench (Single viewer): advances to the next non-deleted image in the current group, and moves to the next duplicate group once the current one is exhausted.

One scope note, recorded as DR-026 in docs/DECISIONS.md: the Duplicates behavior is implemented for the Single (one-at-a-time) viewer, since that's where "advance to the next image" has a well-defined meaning. The Multi comparison grid shows every image in the group simultaneously with no single "current position" to step from, so its existing per-image click actions (mark this one/others DELETE) don't gain new auto-advance behavior — those already trigger their own group-level advance via Keep Best / Delete Group, which is unrelated to this toggle.

Also worth noting: the viewer previously had an unconditional "advance after DELETE" behavior. That's now subsumed by this toggle — the default "Tags & Delete" mode reproduces the old behavior exactly, so nothing changes unless you deliberately switch AoT to Disabled or Delete Only.

This was the final issue in the 10-group plan covering all 19 originally-open issues; all ten dev branches (0.1.38 through 0.1.47) are now pushed and chained in sequence, ready for review/PRs whenever you'd like to proceed with that.

Implemented on branch `0.1.46/issue-109-advance-on-tag` (chained off the previous dev branch, not merged to `main` yet — this is the last of the 10 chained groups covering all 19 open issues). Added a new **AoT** toolbar button immediately to the right of **Tag Filter** that cycles through the three states you described: **Disabled** → **Tags & Delete** (default) → **Delete Only**. The mode is persisted (`PREF_ADVANCE_ON_TAG_MODE`) and restored on next launch, so the toggle itself doubles as "the setting to enable/disable by default" rather than needing a separate Settings-page control. Behavior by area, gated on a tag/DELETE actually being **added** (never on removal), and always ignoring DUPE tags: - **Grid**: selects the next row. - **Image Viewer**: navigates to the next image. - **Duplicate Workbench (Single viewer)**: advances to the next non-deleted image in the current group, and moves to the next duplicate group once the current one is exhausted. One scope note, recorded as **DR-026** in `docs/DECISIONS.md`: the Duplicates behavior is implemented for the **Single** (one-at-a-time) viewer, since that's where "advance to the next image" has a well-defined meaning. The **Multi** comparison grid shows every image in the group simultaneously with no single "current position" to step from, so its existing per-image click actions (mark this one/others DELETE) don't gain new auto-advance behavior — those already trigger their own group-level advance via Keep Best / Delete Group, which is unrelated to this toggle. Also worth noting: the viewer previously had an unconditional "advance after DELETE" behavior. That's now subsumed by this toggle — the default "Tags & Delete" mode reproduces the old behavior exactly, so nothing changes unless you deliberately switch AoT to Disabled or Delete Only. This was the final issue in the 10-group plan covering all 19 originally-open issues; all ten dev branches (`0.1.38` through `0.1.47`) are now pushed and chained in sequence, ready for review/PRs whenever you'd like to proceed with that.

Claude closed this issue

2026-06-20 16:48:00 +00:00

ValleyGeek commented

2026-06-20 21:57:09 +00:00

Author

Owner

The unconditional "advance after DELETE" behavior was broken during a previous fix to keep the image stable while adding tags. Review the code around the delete key and navigation to use only this newly implemented feature. As it exists in 0.1.48 Beta, when 'Hide Deleted' is enabled the AoT on delete isn't triggering. Correct the collision, using the AoT option as the final navigation decision point.

ValleyGeek reopened this issue

2026-06-21 05:18:35 +00:00

Claude referenced this issue from a commit

2026-06-21 05:48:29 +00:00

fix(viewer): make Advance on Tag the sole navigation decision after delete (#109)

Claude commented

2026-06-21 05:48:38 +00:00

Member

Found it — fixed on the same branch (0.1.47/issue-111-86-64-89-feedback-fixes, now at 0.1.50).

_on_viewer_delete_requested() had a leftover guard (hide_prunes) that unconditionally blocked Advance on Tag whenever Hide Deleted was active and the delete was new — exactly the common triage case you ran into. That guard predates AoT and turned out not to be necessary: issue #38's "hold image steady while tagging" mechanism (a pin + deferred resync) already resolves itself correctly inside navigate_next()/advance_to_next_non_deleted() via _go_to_session_index(), which checks for a pending resync before moving. AoT calling that navigation immediately after a delete is exactly "the user navigating away," which is what that mechanism was built to handle — so the extra guard was just incorrectly suppressing AoT rather than protecting anything.

Removed the guard so _should_advance_on_tag() is now the only thing deciding whether to advance after a delete, in either direction:

AoT on (Tags & Delete / Delete Only) → advances correctly even when the delete prunes the image under Hide Deleted.
AoT Disabled → still holds steady exactly as #38 intended.

Added regression tests for both directions with Hide Deleted active. Reopening was right — this was a real bug, not a misunderstanding. Let me know if you hit any other collision spots between AoT and navigation.

Found it — fixed on the same branch (`0.1.47/issue-111-86-64-89-feedback-fixes`, now at 0.1.50). `_on_viewer_delete_requested()` had a leftover guard (`hide_prunes`) that unconditionally blocked Advance on Tag whenever Hide Deleted was active and the delete was new — exactly the common triage case you ran into. That guard predates AoT and turned out not to be necessary: issue #38's "hold image steady while tagging" mechanism (a pin + deferred resync) already resolves itself correctly inside `navigate_next()`/`advance_to_next_non_deleted()` via `_go_to_session_index()`, which checks for a pending resync before moving. AoT calling that navigation immediately after a delete is exactly "the user navigating away," which is what that mechanism was built to handle — so the extra guard was just incorrectly suppressing AoT rather than protecting anything. Removed the guard so `_should_advance_on_tag()` is now the only thing deciding whether to advance after a delete, in either direction: - AoT on (Tags & Delete / Delete Only) → advances correctly even when the delete prunes the image under Hide Deleted. - AoT Disabled → still holds steady exactly as #38 intended. Added regression tests for both directions with Hide Deleted active. Reopening was right — this was a real bug, not a misunderstanding. Let me know if you hit any other collision spots between AoT and navigation.

ValleyGeek commented

2026-06-21 17:00:59 +00:00

Author

Owner

When 'Hide Deleted' is enabled, AoT on the grid doesn't move the selection to the next image. The active selection is completely removed. I suspect an order of operations issue
Other functionality appears to be as intended

- When 'Hide Deleted' is enabled, AoT on the grid doesn't move the selection to the next image. The active selection is completely removed. I suspect an order of operations issue Other functionality appears to be as intended

Claude referenced this issue from a commit

2026-06-21 17:32:20 +00:00

fix(grid,dupe): AoT selection loss with Hide Deleted; multi-view fit/border/pan (#109, #57)

Claude commented

2026-06-21 17:32:28 +00:00

Member

Found and fixed the grid + Hide Deleted bug, pushed to 0.1.47/issue-111-86-64-89-feedback-fixes (0.1.54).

Root cause: Hide Deleted's filter re-evaluates dynamically the instant the DELETE tag is applied, which removes the just-deleted row from the grid's filter and clears the selection model synchronously — before the grid's "advance to next row" logic ever got a chance to read the selection. By the time it ran, there was nothing left to compute "next" from, so the selection just stayed empty.

Fix: the target image to land on is now captured (by path, not row index) before the tag is applied, then re-located in the grid afterward — paths survive the row removal, indices don't. Added regression tests for both this exact scenario and the AoT-disabled case (which correctly stays empty, unchanged).

Please re-test when convenient — particularly grid DELETE with Hide Deleted on, in both AoT modes.

Found and fixed the grid + Hide Deleted bug, pushed to `0.1.47/issue-111-86-64-89-feedback-fixes` (0.1.54). Root cause: Hide Deleted's filter re-evaluates dynamically the instant the DELETE tag is applied, which removes the just-deleted row from the grid's filter *and clears the selection model* synchronously — before the grid's "advance to next row" logic ever got a chance to read the selection. By the time it ran, there was nothing left to compute "next" from, so the selection just stayed empty. Fix: the target image to land on is now captured (by path, not row index) *before* the tag is applied, then re-located in the grid afterward — paths survive the row removal, indices don't. Added regression tests for both this exact scenario and the AoT-disabled case (which correctly stays empty, unchanged). Please re-test when convenient — particularly grid DELETE with Hide Deleted on, in both AoT modes.

Claude commented

2026-06-21 22:57:23 +00:00

Member

Verified — closing.

Claude closed this issue

2026-06-21 22:57:37 +00:00

Claude referenced this issue

2026-06-22 00:35:38 +00:00

feat(tagging): Advance on Tag toggle across Grid, Viewer, and Dupes (#109) #128

Claude referenced this issue from a commit

2026-06-22 00:38:18 +00:00

docs: PR-prep for the 0.1.x feature-tranche close-out - bump to 0.2.0