@tastic/hud 0.6.0 → 0.8.1

package/src/index.ts

@@ -1,8 +1,11 @@
 export { AchievementRow, LOCKED_BADGE_COLOR } from './AchievementRow'
 export { BaseSettingsDialog, type BaseSettingsDialogProps } from './BaseSettingsDialog'
 export { BaseStatsScreen } from './BaseStatsScreen'
+export { ConfirmDialog, type ConfirmDialogProps } from './ConfirmDialog'
 export { ContentGutter } from './ContentGutter'
+export { ControlSchemePicker, type ControlSchemePickerProps } from './ControlSchemePicker'
 export { CornerActionButtons } from './CornerActionButtons'
+export { CornerStatusBadges, type CornerStatusBadgeSeat, type CornerStatusBadgesProps, type OrientationMode } from './CornerStatusBadges'
 export { MONO_FONT } from './fonts'
 export { InlineColorPicker } from './InlineColorPicker'
 export { getLabeledDropdownContentHeight, LABELED_DROPDOWN_POPOVER_WIDTH, LabeledDropdown, type LabeledDropdownOption } from './LabeledDropdown'
@@ -12,16 +15,17 @@ export { PressAwayOverlay } from './PressAwayOverlay'
 export { ReadyButton } from './ReadyButton'
 export { type MenuOption, type MenuSection, type MultiSelectSection, SectionedDropdown, type SingleSelectSection } from './SectionedDropdown'
 export { SharedActionBand } from './SharedActionBand'
+export { SkiaGate, type SkiaGateProps } from './SkiaGate'
 export { StatRow } from './StatRow'
 export { StatSection } from './StatSection'
 // TriggerGauge itself (the raw Skia-based component) is deliberately NOT exported here, even
-// though a native-only consumer could safely skip TriggerGaugeHost's Suspense/lazy-load
-// indirection. A value re-export forces the bundler to fold TriggerGauge.tsx's own `Skia` import
-// into a chunk that this entry point imports eagerly at the top level — since that chunk is then
-// shared with TriggerGaugeHost's lazy dynamic import too, it defeats TriggerGaugeHost's own
-// deferred loading for every consumer, on every platform, not just the ones reaching for the raw
-// component. TriggerGaugeHost is the only supported way to render this.
+// though a native-only consumer could safely skip TriggerGaugeHost's SkiaGate indirection. A
+// value re-export forces the bundler to fold TriggerGauge.tsx's own `Skia` import into a chunk
+// that this entry point imports eagerly at the top level — since that chunk is then shared with
+// TriggerGaugeHost's own dynamic import too, it defeats TriggerGaugeHost's deferred loading for
+// every consumer, on every platform, not just the ones reaching for the raw component.
+// TriggerGaugeHost is the only supported way to render this.
 export type { TriggerGaugeProps } from './TriggerGauge'
 export { default as TriggerGaugeHost } from './TriggerGaugeHost'
-export { type PopoverAlign, type PopoverVerticalAlign, useAutoAlign } from './useAutoAlign'
+export { type PopoverAlign, type PopoverRotation, type PopoverVerticalAlign, useAutoAlign } from './useAutoAlign'
 export { type PopoverHost, usePopoverHost } from './usePopoverHost'

package/src/useAutoAlign.ts

@@ -1,3 +1,4 @@
+import { type ViewRotation } from '@tastic/core'
 import { useCallback, useEffect, useRef, useState } from 'react'
 import { useWindowDimensions, View } from 'react-native'
 
@@ -7,15 +8,55 @@ const EDGE_MARGIN = 12
 
 export type PopoverAlign = 'left' | 'right' | 'center'
 export type PopoverVerticalAlign = 'below' | 'above'
+// Same set of values as @tastic/core's own ViewRotation — re-exported under this package's existing
+// name rather than switching every call site to import ViewRotation directly, since "popover
+// rotation" reads clearer at these call sites than the more general core name.
+export type PopoverRotation = ViewRotation
 
-// Measures a trigger's actual on-screen position (via measureInWindow, which resolves post-
-// transform — this is what makes it correct even for a trigger sitting inside a 180°-rotated zone,
-// unlike a plain onLayout which only ever reports pre-transform local coordinates) and picks
-// whichever alignment keeps a popover of `contentWidth`×`contentHeight` from overflowing a screen
-// edge — horizontally (left/right/center, preferring center) and vertically (below/above,
-// preferring below — the usual case — but flipping to above when the trigger doesn't have enough
-// room underneath it, which is what a short landscape screen with the trigger row near the top
-// actually runs into).
+// Reflects a rect from the PRE-rotation layout frame measureInWindow actually reports (see
+// useAutoAlign's own comment below for why that's what it reports, not the post-rotation visual
+// position) into its true, post-rotation position — needed for a trigger sitting inside a
+// @tastic/split-screen-style FakeLandscapeView, or any other ancestor rotated the same way (a bare
+// CSS `transform: rotate()`, not an actual OS-level orientation change).
+//
+// The pivot is always the window's own center, for every rotation amount: FakeLandscapeView (and
+// this package's own doc-recommended equivalent for a caller that rolls its own) always centers its
+// rotated container — width/height swapped first for ±90°, unchanged for 180° — within the original,
+// un-rotated screen bounds before applying the CSS rotation, so the transform's own effective pivot
+// lands at that shared center regardless of which of the three non-zero rotations it is.
+export function rotateRect(x: number, y: number, width: number, height: number, rotation: PopoverRotation, windowWidth: number, windowHeight: number): { x: number; y: number; width: number; height: number } {
+  if (rotation === 0) return { x, y, width, height }
+  const cx = windowWidth / 2
+  const cy = windowHeight / 2
+  const dx = x + width / 2 - cx
+  const dy = y + height / 2 - cy
+  // Clockwise-positive about (cx, cy) — matches CSS's own rotate(deg) sign convention, which is
+  // where every rotation value this ever receives ultimately comes from (getViewRotation and
+  // FakeLandscapeView both already commit to that same convention).
+  const [newDx, newDy, newWidth, newHeight] = rotation === 180 ? [-dx, -dy, width, height] : rotation === 90 ? [-dy, dx, height, width] : [dy, -dx, height, width]
+  return { x: cx + newDx - newWidth / 2, y: cy + newDy - newHeight / 2, width: newWidth, height: newHeight }
+}
+
+// Measures a trigger's on-screen position (via measureInWindow) and picks whichever alignment keeps
+// a popover of `contentWidth`×`contentHeight` from overflowing a screen edge — horizontally
+// (left/right/center, preferring center) and vertically (below/above, preferring below — the usual
+// case — but flipping to above when the trigger doesn't have enough room underneath it, which is
+// what a short landscape screen with the trigger row near the top actually runs into).
+//
+// measureInWindow resolves the trigger's PRE-transform layout frame — confirmed against a real
+// rotated screen, not just reasoned about: an earlier version of this comment claimed the opposite
+// (that measureInWindow "resolves post-transform"), which is what let a real bug ship unnoticed,
+// since nothing here ever actually exercised a rotated case to catch that claim being wrong (see
+// this file's own test suite, which now does). A plain `onLayout` reports the same pre-transform
+// frame — there is no plain RN layout API that reports a transformed descendant's true visual
+// position, which is exactly why `rotation` below exists: it's the one piece of information this
+// hook cannot recover from measurement alone, since Yoga's layout pass and a CSS `transform` are
+// deliberately independent stages, so the caller has to supply it.
+//
+// `rotation` defaults to 0 (measureInWindow's raw result used as-is) — every existing caller that
+// never sits inside a rotated ancestor keeps behaving identically; only a caller that both (a) can
+// end up inside a @tastic/split-screen-style rotated zone and (b) knows which rotation is currently
+// live needs to pass it (see SectionedDropdown's own `rotation` prop for the wiring this expects).
 //
 // Also returns `maxHeight`: the actual room available in whichever vertical direction got picked.
 // Flipping above-vs-below only ever picks the *better* side — on a screen short enough that neither
@@ -27,7 +68,7 @@ export type PopoverVerticalAlign = 'below' | 'above'
 //
 // Re-measures on every open (not continuously) — the trigger's screen position can't change while
 // its own popover is showing anyway, so there's nothing to gain from tracking it beyond that.
-export function useAutoAlign(open: boolean, contentWidth: number, contentHeight: number) {
+export function useAutoAlign(open: boolean, contentWidth: number, contentHeight: number, rotation: PopoverRotation = 0) {
   const triggerRef = useRef<View>(null)
   const { width: windowWidth, height: windowHeight } = useWindowDimensions()
   const [align, setAlign] = useState<PopoverAlign>('center')
@@ -52,7 +93,8 @@ export function useAutoAlign(open: boolean, contentWidth: number, contentHeight:
   }
 
   const measure = useCallback(() => {
-    triggerRef.current?.measureInWindow((x, y, triggerWidth, triggerHeight) => {
+    triggerRef.current?.measureInWindow((rawX, rawY, rawWidth, rawHeight) => {
+      const { x, y, width: triggerWidth, height: triggerHeight } = rotateRect(rawX, rawY, rawWidth, rawHeight, rotation, windowWidth, windowHeight)
       const centerX = x + triggerWidth / 2
       const overflowsRight = centerX + contentWidth / 2 > windowWidth - EDGE_MARGIN
       const overflowsLeft = centerX - contentWidth / 2 < EDGE_MARGIN
@@ -72,14 +114,14 @@ export function useAutoAlign(open: boolean, contentWidth: number, contentHeight:
       setMaxHeight(Math.max(above ? roomAbove : roomBelow, 0))
       setMeasured(true)
     })
-  }, [contentWidth, contentHeight, windowWidth, windowHeight])
+  }, [contentWidth, contentHeight, windowWidth, windowHeight, rotation])
 
   // Re-measures whenever `open` flips true, and also if `measure` itself changes identity (i.e.
-  // contentWidth/contentHeight/windowWidth/windowHeight changed) while already open — e.g. a live
-  // window resize — so it never goes stale while the popover is actually showing. `measured` only
-  // resets on a genuine (re)open, via the render-phase check above — not here on every re-measure,
-  // so an already-visible popover never flickers hidden again just because the window resized
-  // under it.
+  // contentWidth/contentHeight/windowWidth/windowHeight/rotation changed) while already open — e.g.
+  // a live window resize, or the device being physically turned while the popover is showing — so it
+  // never goes stale while the popover is actually showing. `measured` only resets on a genuine
+  // (re)open, via the render-phase check above — not here on every re-measure, so an already-visible
+  // popover never flickers hidden again just because the window resized (or rotated) under it.
   useEffect(() => {
     if (open) measure()
   }, [open, measure])