feat(grid): add Reveal in Filesystem to the grid context menu (#116) #144

Merged
ValleyGeek merged 5 commits from 0.2.4/issue-116-locate-filesystem into main 2026-06-25 06:26:50 +00:00
Member

Summary

  • Grid: right-click a single image and choose Reveal in Filesystem to open it in the native OS file manager with the file selected. Uses Windows Explorer's /select on Windows (local and network paths); on Linux, the first detected of Nautilus, Dolphin, Nemo, or PCManFM, falling back to opening the containing folder via xdg-open if none of those are installed.
  • Fixed a Windows bug found in testing: subprocess.Popen on Windows re-quotes a list of args via list2cmdline(), which corrupted the literal /select,"<path>" quoting explorer.exe expects — it silently fell back to opening Documents instead of selecting the file, on both local and network (UNC) paths. Fixed by passing the whole command as one pre-formed string on Windows instead of a list.
  • Also fixes a related CI bug uncovered while trying to get a fresh Windows build to verify the fix: Linux and Windows release jobs share one dev-release tag, and one platform's publish moving the shared target_commitish forward could make the other platform's stale, pre-fix asset look "already built" for the new commit just because an asset with the right suffix happened to still be attached. release_build_needed.py now also checks that the matched asset's upload time is at or after the target commit's own commit date.

Bumps VERSION to 0.3.4.

Test plan

  • pytest — full suite passes (629 passed, 1 skipped)
  • ruff check / ruff format --check pass
  • scripts/smoke-ui-exit.sh — clean Qt teardown
  • New tests for the per-platform reveal command construction, the Windows single-string-vs-list Popen invocation, and the release-asset-staleness CI fix
  • Manually exercised in a real directory with 2,200 images; Windows quoting fix and CI staleness fix verified via the actual dev-release build pipeline
## Summary - Grid: right-click a single image and choose **Reveal in Filesystem** to open it in the native OS file manager with the file selected. Uses Windows Explorer's `/select` on Windows (local and network paths); on Linux, the first detected of Nautilus, Dolphin, Nemo, or PCManFM, falling back to opening the containing folder via `xdg-open` if none of those are installed. - Fixed a Windows bug found in testing: `subprocess.Popen` on Windows re-quotes a list of args via `list2cmdline()`, which corrupted the literal `/select,"<path>"` quoting `explorer.exe` expects — it silently fell back to opening Documents instead of selecting the file, on both local and network (UNC) paths. Fixed by passing the whole command as one pre-formed string on Windows instead of a list. - Also fixes a related CI bug uncovered while trying to get a fresh Windows build to verify the fix: Linux and Windows release jobs share one dev-release tag, and one platform's publish moving the shared `target_commitish` forward could make the *other* platform's stale, pre-fix asset look "already built" for the new commit just because an asset with the right suffix happened to still be attached. `release_build_needed.py` now also checks that the matched asset's upload time is at or after the target commit's own commit date. Bumps VERSION to 0.3.4. ## Test plan - [x] `pytest` — full suite passes (629 passed, 1 skipped) - [x] `ruff check` / `ruff format --check` pass - [x] `scripts/smoke-ui-exit.sh` — clean Qt teardown - [x] New tests for the per-platform reveal command construction, the Windows single-string-vs-list Popen invocation, and the release-asset-staleness CI fix - [x] Manually exercised in a real directory with 2,200 images; Windows quoting fix and CI staleness fix verified via the actual dev-release build pipeline
Right-click a single image in the main Grid workbench and choose
"Reveal in Filesystem" to open the OS file manager with that file
selected. core/reveal_in_filesystem.py builds the platform command:
explorer /select on Windows; the first detected of nautilus/dolphin/
nemo/pcmanfm on Linux, falling back to xdg-open on the containing
directory if none of those is installed; `open -R` on macOS as a
trivial fallback (non-goal platform, not polished further). Launch is
non-blocking (subprocess.Popen, no wait) and missing files are logged
and skipped rather than raising.

Threading notes: triggered synchronously from a context-menu action on
the main thread; not a worker. No QWidget/QPixmap access happens off
the main thread, and the one-shot subprocess launch never blocks the
event loop since the child process is never waited on.
This branch stacks on the unmerged v0.3 tranche
(138 -> 136 -> 113 -> 131 -> 116), already at 0.3.3. Continue the
sequence to 0.3.4, the tranche's final release. bump-version.sh
itself only knows origin/main's 0.2.4 and would have produced 0.2.5
here (the same bug fixed on the #136 branch), so VERSION was set by
hand and verified via a refreshed editable install.
subprocess.Popen on Windows re-quotes a list of args via list2cmdline() into
a single command line for CreateProcess. That re-quoting escapes the literal
double quotes already wrapped around the path in the constructed
/select,"<path>" argument -- explorer.exe's own non-shell argument parser
doesn't understand that escaping, and silently falls back to opening the
default folder (Documents) instead of selecting the file. Reproduced on both
a local directory and a network (UNC) path per the report; same root cause
either way since it's purely a command-line-construction bug, not path
resolution.

Fixed by passing the whole command as one pre-formed string on win32 instead
of a list -- subprocess.Popen uses a string command line verbatim (no
list2cmdline reprocessing), which is the standard workaround for this
well-known explorer /select, quoting issue. macOS/Linux still pass a list
(no shell-string reconstruction happens on those platforms, so no quoting
hazard).

Threading notes: no change -- still a non-blocking Popen call from a
main-thread context-menu action.
VERSION stays at 0.3.4 -- correcting the not-yet-released entry in place.
Linux and Windows share one release tag per dev branch/version. When one
platform rebuilds and its publish step moves the shared target_commitish
forward to a new head commit, the other platform's build-needed check was
seeing "target_commitish == head" plus "an asset with my suffix is attached"
and concluding it was already built for that head -- even when that asset
was actually uploaded for an earlier commit and never rebuilt for this one.

This is exactly what happened on the 0.2.4/issue-116-locate-filesystem dev
release: the attached .exe was built from the original PR-prep commit
(76fe053, 2026-06-24T14:28 UTC upload), but a later push that fixed the
actual Windows bug moved target_commitish to a docs-only commit
(d3b3452, committed 2026-06-25T00:51 UTC) once Linux's job republished the
AppImage for it. The Windows check saw the (stale) .exe by name, matched the
already-advanced target_commitish, and skipped rebuilding -- leaving no
artifact anywhere that actually contained the fix to test on Windows.

_release_has_platform_asset() now also requires the matched asset's upload
time to be at or after the target commit's own commit date -- an asset
genuinely built for that commit can only have been uploaded after the commit
existed, so a stale leftover (uploaded for some earlier commit) can never
satisfy that check. fetch_release_info() now returns each asset's created_at
alongside its name to make this possible.

This is the same failure family as PR #100 (asset name presence was added
specifically so the other platform's earlier publish wouldn't make this
platform's *missing* asset look present); this closes the remaining gap
where the asset is present but stale.
ValleyGeek deleted branch 0.2.4/issue-116-locate-filesystem 2026-06-25 06:26:50 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ai-collab/bulk-image-organizer!144
No description provided.