What changed
Before 2.0, video previews were a <video> element in the Electron renderer, with controls and an autoplay setting. The move to GPUI (ADR 0002) removed that: GPUI has no video element.
Video files now show the poster frame Quick Look produces, and O opens the file in QuickTime. The videoAutoplay setting was dropped because it no longer had anything to control.
This is the one feature regression in 2.0 and it's worth tracking rather than quietly accepting.
What was ruled out
gpui-video-player is the only third-party option. It's built on GStreamer and requires GStreamer plus its plugins installed system-wide. Demanding that of everyone who downloads a 13 MB app is a worse trade than the missing playback.
Suggested approach: a scrubbable filmstrip
Rather than reinstating playback, extract N frames at even intervals with AVAssetImageGenerator (objc2-av-foundation, and copyCGImageAtTime: / generateCGImagesAsynchronouslyForTimes: are the relevant calls) and map horizontal cursor position or ←/→ across them.
For deciding whether to keep a screen recording, that's arguably better than playback ever was: you read the whole video in one drag instead of waiting through it. It also fits how the rest of the app works — every other format is a still image from the same kind of native API.
Notes for whoever picks this up:
preview.rs already has the pattern for bridging an async, block-based macOS API into a blocking call with a timeout — thumbnail_png does exactly this for QLThumbnailGenerator, and the frame generator is the same shape.- Frames are large. The current Quick Look thumbnails run to ~1.8 MB of PNG for a 1600pt render, so a 12-frame strip wants a much smaller per-frame size than the full preview uses.
- Keep the
O binding regardless — it's the correct escape hatch for anything the app can't render, video included.
Alternative
Embed an AVPlayerView as a native child NSView over the GPUI window via objc2. Restores real playback, but GPUI owns the window's content view, so z-ordering and clipping against GPUI-drawn content get awkward. Worth a look only if the filmstrip turns out to be insufficient.
What changed
Before 2.0, video previews were a
<video>element in the Electron renderer, with controls and an autoplay setting. The move to GPUI (ADR 0002) removed that: GPUI has no video element.Video files now show the poster frame Quick Look produces, and
Oopens the file in QuickTime. ThevideoAutoplaysetting was dropped because it no longer had anything to control.This is the one feature regression in 2.0 and it's worth tracking rather than quietly accepting.
What was ruled out
gpui-video-playeris the only third-party option. It's built on GStreamer and requires GStreamer plus its plugins installed system-wide. Demanding that of everyone who downloads a 13 MB app is a worse trade than the missing playback.Suggested approach: a scrubbable filmstrip
Rather than reinstating playback, extract N frames at even intervals with
AVAssetImageGenerator(objc2-av-foundation, andcopyCGImageAtTime:/generateCGImagesAsynchronouslyForTimes:are the relevant calls) and map horizontal cursor position or←/→across them.For deciding whether to keep a screen recording, that's arguably better than playback ever was: you read the whole video in one drag instead of waiting through it. It also fits how the rest of the app works — every other format is a still image from the same kind of native API.
Notes for whoever picks this up:
preview.rsalready has the pattern for bridging an async, block-based macOS API into a blocking call with a timeout —thumbnail_pngdoes exactly this forQLThumbnailGenerator, and the frame generator is the same shape.Obinding regardless — it's the correct escape hatch for anything the app can't render, video included.Alternative
Embed an
AVPlayerViewas a native childNSViewover the GPUI window viaobjc2. Restores real playback, but GPUI owns the window's content view, so z-ordering and clipping against GPUI-drawn content get awkward. Worth a look only if the filmstrip turns out to be insufficient.