Repository navigation
fix(cli): let the Linux portal select recording sources - #1080
Conversation
|
Important Review skippedReview was skipped as selected files did not have any reviewable changes. ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to On Linux with the native PipeWire helper, recording no longer enumerates Chromium sources before the portal picker opens. Other platforms keep their existing source selection. No merge-blocking risk was found. Pre-merge checks |
|
|
@coderabbitai review |
|
|
Marked ready: CI green; follow-up logs that the portal picks the source, and drops the results-log row that recorded no manual check. |
|
@coderabbitai review |
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
EtienneLescot
left a comment
There was a problem hiding this comment.
Reviewed: the Linux portal owns source selection on the native path, other capture paths unchanged. Thanks @mcmah309!
c5b2a95 to
c187ecb
Compare
Summary
openscreen recordon Linux with the native PipeWire helper no longer enumerates Chromium sources first. That enumeration raised a redundant portal picker before the helper's own, and could return no screens (Display index 0 not found). The portal now chooses the source, as it already does in the HUD; the CLI logs that--displayand--windowdo not apply there.Other capture paths are unchanged: Windows, macOS and Linux without the helper still pick and validate a source through
pickSource+selectSource.Type of change
Release impact
Desktop impact
Screenshots / video
Testing
src/cli/CliRecordRunner.test.tsx: native Linux skips enumeration and selection; Linux without the helper still selects, and reports a missing display.🤖 Generated with Claude Code
Summary by CodeRabbit
--displayand--windowdon’t apply in this mode.