Skip to content

feat(shelf): add non-interruptive post-capture workflow - #88

Open
tony-roslund wants to merge 9 commits into
omacom:mainfrom
tony-roslund:feat/post-capture-handoff
Open

feat(shelf): add non-interruptive post-capture workflow#88
tony-roslund wants to merge 9 commits into
omacom:mainfrom
tony-roslund:feat/post-capture-handoff

Conversation

@tony-roslund

Copy link
Copy Markdown

Summary

Adds a non-interruptive post-capture Shelf to Omasnap. Existing capture and annotation behavior is reused; successful screenshots now go directly to the clipboard and a bottom-right Shelf instead of opening the editor automatically.

This is separate from Omasnap 1.19's in-overlay recents shelf: the new post-capture Shelf stays available after capture while the user continues working.

Workflow and functionality

  • Preserve Omasnap's existing region, window, fullscreen, and scrolling capture behavior.
  • Immediately copy every completed screenshot as PNG image data, ready for Ctrl+V.
  • Add the capture to a bottom-right Shelf without focusing it or opening the editor.
  • Keep up to five captures, with the newest thumbnail at the front.
  • Click the thumbnail stack to expand all thumbnails.
  • Hover a thumbnail to reveal Annotate, Copy, and Remove actions.
  • Click a thumbnail, or choose Annotate, to open it in Omasnap's existing editor.
  • Save or press Enter after annotation to update the same Shelf item instead of creating a duplicate.
  • Copy directly from the in-memory thumbnail so it still works if a temporary backing file has disappeared.
  • Remove only Omasnap-owned private runtime snapshots; never delete arbitrary user files.
  • Click and drag the stacked Shelf downward to tuck/hide all thumbnails off-screen.
  • Click the small bottom handle to restore the Shelf.
  • Automatically hide the Shelf while the compositor captures the next screenshot so thumbnails never appear in the capture.
  • Restore the Shelf when capture completes or is cancelled.
  • Support rapid sequential captures through one Shelf process and local IPC.
  • Keep the Shelf non-focus-stealing, bottom-right anchored, and monitor-aware.

Scope

  • No cloud upload, provider, authentication, or sharing support.
  • No screen recording changes.
  • No replacement capture engine.
  • No replacement annotation editor.
  • Omasnap 1.19's scrolling capture remains unchanged.
  • Omasnap 1.19's in-overlay recents shelf remains intact.

Safety and lifecycle

  • Shelf snapshots live in Omasnap's private runtime directory.
  • The Shelf owns and cleans only paths matching its private shelf-*.png format.
  • Annotation reconstructs a missing backing snapshot from its in-memory image before opening the editor.
  • Up to five captures are retained for the running session.

Verification

  • Rebased onto Omasnap 1.19.1 (a07a68d).
  • Full make check passes.
  • Headless smoke coverage for post-capture handoff, newest-first/maximum-five layout, annotation replacement round-trip, and clipboard image-data copying.
  • Live Omarchy/Hyprland verification of the capture overlay, bottom-right Shelf layer, automatic Shelf hiding during capture, and restoration after cancellation.
  • The tested binary is installed locally at ~/.local/bin/omasnap, with Print Screen wired to omasnap --capture-region.

@jondkinney

Copy link
Copy Markdown
Collaborator

Great concept! I wonder if this would be better to bake into the current pin capability? I have a PR that improves the layout/organization of the pins #82 but having an option to "capture straight to pin" could re-use a good bit of the existing machinery.

@tony-roslund

tony-roslund commented Aug 24, 2026

Copy link
Copy Markdown
Author

Thanks! “Capture straight to pin” is close to the workflow I’m aiming for, especially in that the editor is skipped immediately after capture. The capture is copied to the clipboard right away and parked so the user can continue working, then open it in the editor later when they’re actually ready to annotate it.

The main UX difference is compactness. Rather than displaying each capture as a full floating pin, this PR keeps up to five captures in a small stacked shelf. The stack can also be dragged almost entirely off-screen, leaving only a small handle, so captures remain available without occupying working space. Later, the user can restore and expand the stack, then click a capture to edit, copy, or remove it.

It might make sense to support both approaches and let users choose their preferred post-capture behavior within the app: traditional floating pins or the compact stacked shelf. There may also be an opportunity to reuse some of the pin machinery—particularly the placement and organization improvements from #82—while preserving the shelf’s compact, tuck-away behavior.

So the goal is essentially a “capture now, use or edit later” workflow, with a choice in how those captures stay available. Does that distinction make sense, and do you think offering both floating pins and a compact stacked mode would fit well with the direction you have in mind for pins?

here's a video of this in action: https://x.com/tonyroslund/status/2091644707646366074/video/1

@tony-roslund
tony-roslund force-pushed the feat/post-capture-handoff branch from 0ee088e to df05170 Compare August 28, 2026 14:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants