Catch-all commit for outstanding pre-existing local changes. Mixes
several themes that would normally be split:
- Rename: UxPlugin → XPlugin across iOS, macOS, Android registrants.
- New top-level packages under lib/src/: anim/ (animated values,
panes, sheets, dock, measured), core/ (Emitter, ReactiveBuilder
scaffolding, presenter/widget/value/dispose primitives), navi/
(Screen/ScreenStack/Router/hero/transitions), reactive/.
- Edits across existing plugins (clipboard, crash, file, gallery,
keyboard, scanner, sensor, url) to align with the new core.
- Test updates and CHANGELOG/README touches accompanying the above.
Diagnostic from a fresh build with NSLog confirmed the rotation
behaviour on macOS: with `videoRotationAngle = 90`
(`.portrait`), `AVCapturePhoto.cgImageRepresentation()` returned a
720x1280 CGImage — *physical* portrait pixels, not just an EXIF
tag. So Apple's AVCaptureSession.h docs claiming
"AVCapturePhotoOutput uses EXIF only" don't hold on macOS. The
data-output connection on macOS also honors the same setter, which
is why preview + video flipped to rotated as soon as the photo fix
landed.
Pin macOS to 0° rotation (`.landscapeRight`):
- Photo: 1280x720 (sensor-native landscape, matches what the user
sees on screen).
- Preview: 1280x720 (matches the new desktop 4:3 page aspect).
- Video: 1280x720 (was already correct before the .portrait
change; back to that state).
The snapshot orientation argument is still ignored on macOS —
desktop cameras don't rotate. The argument carries through for iOS
where the camera page passes the device orientation.
`.landscapeRight` / `videoRotationAngle = 0` both still produced a
JPEG rotated 90° CW on macOS. User verified that `.portrait` /
`videoRotationAngle = 90` is the value that DOES NOT rotate the
captured frame on the photo output's connection — counter to the
iOS convention where `.portrait` rotates the landscape sensor
frame into portrait pixels.
I'd expect this to be macOS-specific photo-pipeline plumbing; the
data output's connection still doesn't honor the setter (isSupported
returns false or the setter no-ops), so preview + video stay
unaffected. Verified empirically; not chasing the AVFoundation
source for the why.
Setting `videoOrientation = .landscapeRight` had no effect on
macOS 14+ — Apple deprecated it in favour of `videoRotationAngle`
(a `CGFloat` in degrees) and the old setter is silently ignored
in newer versions. The captured JPEG stayed rotated 90° CW even
with our previous fix.
Try `videoRotationAngle = 0` first (macOS 14+) — that's "no
rotation from the sensor's natural orientation", which is landscape
on desktop cameras. Fall back to `videoOrientation = .landscapeRight`
for macOS 13 and older.
Same `applyUxCaptureOrientation` entry point — no caller changes.
iOS extension untouched; iOS still uses the per-snapshot
`videoOrientation` set (deprecated on iOS 17+ too, but still
functions there).
`AVCaptureVideoDataOutput`'s connection on macOS doesn't honor
`videoOrientation` (or its `isVideoOrientationSupported` is false) —
which is why the preview + recorded video were landscape and looked
fine even with our previously-no-op extension. `AVCapturePhotoOutput`'s
connection on macOS *does* honor it, and its default is `.portrait`
— same as iOS — so leaving it untouched rotated the captured JPEG 90°
CW relative to the landscape sensor.
The extension now sets `.landscapeRight` unconditionally (guarded by
`isVideoOrientationSupported`, so on the data output it's a no-op):
photo connection pins to landscape, JPEG EXIF orientation = 1 (no
rotation), captured image matches the preview.
Video + preview already correct → unaffected.
macOS preview was stretching (aspect wrong) and macOS photo capture
was rotating the landscape sensor 90° because the shared
PhotoOutput / CameraInstance code was setting
`AVCaptureConnection.videoOrientation` from the orientation snapshot
unconditionally. iOS needs that to rotate sample buffers to portrait;
macOS desktop cams are physically landscape and any rotation just
skews the result.
Moved the rotation call behind a per-platform extension on
`AVCaptureConnection`:
- `ios/Classes/Camera/AVCaptureConnection+iOS.swift` applies the
snapshot orientation (current behavior).
- `macos/Classes/Camera/AVCaptureConnection+macOS.swift` is a
no-op. macOS-flavoured photos / preview frames now flow at
native landscape orientation.
`CaptureDevice` reports sensorOrientation=0 on macOS (was hardcoded
90 for iOS); on macOS the page's `normalizeCameraCapture` math then
collapses to identity and the saved JPEG stays the landscape the
sensor produced. iOS keeps sensorOrientation=90 (matches
camera_avfoundation's reported value and the existing capture-
transform math).
Photo and video paths now both produce upright content on macOS
(video already worked because VideoRecorder's transform table maps
the always-portraitUp macOS snapshot to `.identity`).
