Let macOS offer the app for a video - #4
Merged
Conversation
Video has been readable since 1.6.0, but the macOS bundle never claimed the type, so the app does not appear under "Open With" for an .mp4 in Finder — the only ways in are the app's own file picker, dropping the file on the window, or a path on the command line. This is the same omission fixed for PDFs in e00e90e, found while checking that one. One entry covers all six formats the app reads. Every one of them has a system-declared type that conforms to public.movie, which is worth stating because it is not true of the obvious alternative reading — .mkv and .webm have no Apple-supplied type and might reasonably have fallen back to a dynamic UTI conforming only to public.data: mp4 public.mpeg-4 conforms to public.movie mov com.apple.quicktime-movie conforms to public.movie m4v com.apple.m4v-video conforms to public.movie avi public.avi conforms to public.movie mkv org.matroska.mkv conforms to public.movie webm org.webmproject.webm conforms to public.movie public.movie also takes in formats the app does not read, which get the ordinary "not a file type this app can read" message. That is the existing bargain rather than a new one: public.plain-text has always offered the app for every .json and .py on the disk. LSHandlerRank stays Alternate, so nothing is taken away from QuickTime. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
mediaswing
added a commit
that referenced
this pull request
Aug 17, 2026
`cargo fmt --check` has been failing on every commit since ef1bf0b "Read PDFs aloud", which landed 15 unformatted hunks; the two PDF commits after it added two more. 1.7.0 was the last green build. Nothing here is a change to the code. It is what `cargo fmt` produces with the default settings and no `rustfmt.toml`, confined to `src/extract/pdf/`: line breaking, argument wrapping, and one trailing blank line. Every comment is untouched. Worth doing on its own rather than inside the next change to these files, because a red Formatting check on an unrelated pull request is a check people learn to ignore — and it was already costing that on #4, which touches nothing but a workflow YAML. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Video has been readable since 1.6.0, but the macOS bundle never claimed the type.
LSItemContentTypesis what builds Finder’s Open With submenu, so today the app does not appear there for an.mp4— the only ways in are the app’s own file picker, dropping the file on the window, or a path on the command line.Same omission as the one fixed for PDFs in e00e90e; found while checking that one. Filed for the next round of fixes rather than folded into the 1.8.0 release, which was about PDFs.
The fix
One line —
public.movie— because every format the app reads conforms to it:public.movie.mp4public.mpeg-4.movcom.apple.quicktime-movie.m4vcom.apple.m4v-video.avipublic.avi.mkvorg.matroska.mkv.webmorg.webmproject.webmWorth stating, because the obvious worry does not hold:
.mkvand.webmhave no Apple-supplied type and could reasonably have fallen back to a dynamic UTI conforming only topublic.data. They do not — checked withUTType(filenameExtension:).conforms(to: .movie)on macOS 26.5 rather than assumed.Trade-off
public.moviealso offers the app for formats it does not read (.flv,.mpg), which get the ordinary “not a file type this app can read” message. That is the existing bargain rather than a new one —public.plain-texthas always offered the app for every.jsonand.pyon the disk. The alternative is six explicit entries that need editing whenever a format is added.LSHandlerRankstaysAlternate, so nothing is taken away from QuickTime.Note on scope
While checking this I also verified that
.csv/.tsvare already covered — both conform topublic.plain-text, which has always been declared. I had earlier thought they were missing too; they are not, and this PR does not touch them.Testing
Not observable until a tagged build produces a bundle, since the plist is generated in the release workflow. The workflow YAML still parses, and the change is inside the
Package (macOS)heredoc only — no effect on the Windows job or oncargoanything.🤖 Generated with Claude Code