[Feature]: Locate on Filesystem #116

Closed
opened 2026-06-21 23:58:03 +00:00 by ValleyGeek · 3 comments
Owner

Problem or use case

No way to locate the file being viewed

Proposed solution

On the grid, add "Reveal in Filesystem" to the right-click context menu to open the directory and highlight the image using the native OS directory explorer.

Alternatives considered

No response

### Problem or use case No way to locate the file being viewed ### Proposed solution On the grid, add "Reveal in Filesystem" to the right-click context menu to open the directory and highlight the image using the native OS directory explorer. ### Alternatives considered _No response_
Member

Implemented on branch 0.2.4/issue-116-locate-filesystem (pushed, stacked on 0.2.4/issue-131-next-unreviewed-button, awaiting PR to main):

  • Right-click a single image in the main Grid workbench and choose Reveal in Filesystem to open it in the native OS file manager with the file selected.
  • core/reveal_in_filesystem.py builds the platform command: explorer /select,"<path>" on Windows; on Linux, the first detected of Nautilus, Dolphin, Nemo, or PCManFM (using each one's own "select" flag), falling back to xdg-open on the containing directory if none of those are installed; a trivial open -R fallback on macOS (non-goal platform, not polished further).
  • Launch is non-blocking (subprocess.Popen, never waited on) so a slow/misbehaving file manager can't stall the UI. A missing file (deleted/moved since the last scan) is logged and skipped rather than raising.

Added tests/test_reveal_in_filesystem.py (11 tests covering command construction per platform/tool and the missing-file/no-tool/OSError fallback paths). Full suite: 614 passed/1 skipped (up from 603 baseline), ruff clean, smoke-ui-exit.sh clean. This is the fifth and final branch in the v0.3.0 tranche (VERSION now 0.3.4).

Implemented on branch `0.2.4/issue-116-locate-filesystem` (pushed, stacked on `0.2.4/issue-131-next-unreviewed-button`, awaiting PR to `main`): - Right-click a single image in the main Grid workbench and choose **Reveal in Filesystem** to open it in the native OS file manager with the file selected. - `core/reveal_in_filesystem.py` builds the platform command: `explorer /select,"<path>"` on Windows; on Linux, the first detected of Nautilus, Dolphin, Nemo, or PCManFM (using each one's own "select" flag), falling back to `xdg-open` on the containing directory if none of those are installed; a trivial `open -R` fallback on macOS (non-goal platform, not polished further). - Launch is non-blocking (`subprocess.Popen`, never waited on) so a slow/misbehaving file manager can't stall the UI. A missing file (deleted/moved since the last scan) is logged and skipped rather than raising. Added `tests/test_reveal_in_filesystem.py` (11 tests covering command construction per platform/tool and the missing-file/no-tool/OSError fallback paths). Full suite: 614 passed/1 skipped (up from 603 baseline), ruff clean, `smoke-ui-exit.sh` clean. This is the fifth and final branch in the v0.3.0 tranche (`VERSION` now `0.3.4`).
Member

Fixed the Windows bug from testing, pushed to the same branch (0.2.4/issue-116-locate-filesystem):

Root cause: subprocess.Popen on Windows reconstructs a list of args into a single command line via list2cmdline(), which re-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 — reproducible on both a local directory and a network (UNC) path, since it's a pure command-line-construction bug, not a path-resolution one.

Fix: pass the whole command as one pre-formed string on Windows instead of a list — Popen uses a string command line verbatim with no re-quoting, which is the standard workaround for this explorer /select, quoting issue. macOS/Linux are unaffected (no shell-string reconstruction happens there).

Still open pending PR/merge to main.

Fixed the Windows bug from testing, pushed to the same branch (`0.2.4/issue-116-locate-filesystem`): Root cause: `subprocess.Popen` on Windows reconstructs a list of args into a single command line via `list2cmdline()`, which re-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 — reproducible on both a local directory and a network (UNC) path, since it's a pure command-line-construction bug, not a path-resolution one. Fix: pass the whole command as one pre-formed string on Windows instead of a list — `Popen` uses a string command line verbatim with no re-quoting, which is the standard workaround for this `explorer /select,` quoting issue. macOS/Linux are unaffected (no shell-string reconstruction happens there). Still open pending PR/merge to `main`.
Member

Closing — PR #144 is open against main.

Closing — PR #144 is open against `main`.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
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#116
No description provided.