Files
openchamber/packages/ui/src/lib/hardwareKeyboard.ts
T
Bohdan Triapitsyn 96c011a8ef feat(mobile): tablet layout pass and foldable-ready size class (#2569)
The tablet ran the phone layout with a half-finished iPad draft on top: two
custom sidebars, a leftover overflow menu, split Files/Changes header buttons,
and phone-width sheets stretched across a 13" screen. This brings it onto the
phone's navigation model and keeps only the differences a large screen earns.

- Sessions are a persistent resizable left sidebar; the overflow menu is gone
  and its destinations moved into that sidebar's footer (connected instance,
  settings, pending web update) and into the workspace drawer.
- The workspace (Changes / Files / Terminal / Notes / MCP) is the phone's
  drawer everywhere: a resizable right sidebar where the screen can host one
  (up to 900px) and the full-cover drawer otherwise, with its mounted panes —
  an open diff, an edited file, an attached terminal — surviving rotation.
- Header dropdowns are anchored popovers: the recents switcher mirrors the
  usage overlay on the left, and its trigger is sized to the title rather than
  to the free width.
- App-level pages (settings, instances, update, an opened plan) render as
  centered dialogs instead of covering the screen.
- Overlays center on the chat column through published insets, so the model
  and directory pickers no longer sit off-centre; the directory picker also
  stops overriding the shared width clamp.
- Wide chat layout applies to mobile surfaces, where a tablet chat column is
  finally wide enough for the setting to mean anything.

The layout gate is a live size class rather than a device check, so Android
tablets and foldables are covered by the same code:

- `enabled` when the shortest viewport side is at le
  sw600dp). The short side is what makes this a size question instead of a
  device question — a phone reports ~360-430 whichev
  unfolded book foldable ~600+, and folding shut drops back under it. iPads
  also answer on identity, since iPadOS hands out od
- `roomyForPanels` when landscape and at least 1000px wide, which is what it
  takes to host the sidebar, the panel and a readabl
  foldables miss it in BOTH orientations — their long side is barely wider
  than a tablet's short one — so they keep the portr

Every consumer re-decides instead of remembering wha
open sidebar closes if the device folds shut under it. iPad behaviour is
unchanged: its landscape widths all clear the panel
ones do not, exactly as the previous orientation check did.

Hardware keyboards are read natively. iOS reports them through GCKeyboard,
published to the web layer at document start and kep
disconnect and foregrounding; the layer stops inferring once that answers. A
single early publish was not enough — the connect no
already-attached keyboard fires before the page exists, and GameController can
populate late — so the state is re-published across
resume. With a keyboard attached the draft screen keeps its starter chips and
the composer never collapses; tablets skip the colla
Runtimes with no native answer fall back to inferring it from the keyboard
bridge, and only ever conclude "hardware" from silen

Also: sidebar rows no longer sit on a differently ti
footer is no longer clipped by an over-tall content box, the resize handles
moved above the panes' own overlays so they can actu
now-unreachable overflow menu, fullscreen terminal/MCP/notes surfaces and their
locale key are deleted.

Device behaviour is unverified — the tablet layout,
keyboard bridge and the foldable size class have not been exercised on
hardware, and the 600/1000 thresholds are derived fr
rather than measured on a foldable.
2026-08-02 16:25:16 +03:00

158 lines
5.7 KiB
TypeScript

/**
* "Is a hardware keyboard attached?" — the input the mobile layout uses to
* decide whether a soft keyboard will ever eat the screen.
*
* Two sources, in priority order:
*
* 1. The native answer. On iOS the shell reads `GCKeyboard` and stamps
* `window.__OPENCHAMBER_HARDWARE_KEYBOARD__` at document start, then keeps it
* live via `oc:hardware-keyboard` (see BridgeViewController). This is
* authoritative and — crucially — known BEFORE the user focuses anything, so
* the draft screen and composer start in the right shape instead of
* re-laying-out after the first focus.
* 2. Inference, for runtimes with no native answer (Android, hosted mobile).
* A `keyboardWillShow` with a real height means there IS a soft keyboard; a
* tiny height means only iOS' shortcut strip; focus with no event at all
* within a short window means nothing was presented. Inference is ignored
* entirely once the native source has spoken.
*
* Everything else stays `false`, which is the safe default: the layout then
* behaves exactly as it does on a phone.
*
* In memory only — a keyboard can be attached and detached while the app runs,
* and both sources re-answer the question continuously.
*/
import React from 'react';
/** Below this the "keyboard" is only iOS' shortcut bar, not a real keyboard. */
const SOFTWARE_KEYBOARD_MIN_HEIGHT_PX = 120;
/** iOS starts its keyboard animation well inside this window after focus. */
const KEYBOARD_EVENT_GRACE_MS = 600;
declare global {
interface Window {
__OPENCHAMBER_HARDWARE_KEYBOARD__?: boolean;
}
}
// Read at module init, not just from the bridge effect: the stamp exists from
// document start, and the very first render of the draft screen / composer must
// already see it — otherwise the layout still settles one frame late.
const initialNativeAnswer = typeof window !== 'undefined'
&& typeof window.__OPENCHAMBER_HARDWARE_KEYBOARD__ === 'boolean'
? window.__OPENCHAMBER_HARDWARE_KEYBOARD__
: null;
let hardwareKeyboardAttached = initialNativeAnswer === true;
let hasNativeAnswer = initialNativeAnswer !== null;
let focusProbeTimer: number | null = null;
let bridgeStarted = false;
const subscribers = new Set<() => void>();
if (hardwareKeyboardAttached && typeof document !== 'undefined') {
document.documentElement.classList.add('oc-hardware-keyboard');
}
const clearFocusProbe = (): void => {
if (focusProbeTimer === null) return;
window.clearTimeout(focusProbeTimer);
focusProbeTimer = null;
};
const setHardwareKeyboardAttached = (value: boolean): void => {
if (hardwareKeyboardAttached === value) return;
hardwareKeyboardAttached = value;
if (typeof document !== 'undefined') {
document.documentElement.classList.toggle('oc-hardware-keyboard', value);
}
for (const listener of subscribers) listener();
};
/**
* Adopt the native shell's answer and stop inferring. Idempotent; safe to call
* before the shell has stamped anything (then it is a no-op and inference
* stays in charge).
*/
export const startHardwareKeyboardBridge = (): (() => void) => {
if (typeof window === 'undefined') return () => {};
const adopt = (value: boolean) => {
hasNativeAnswer = true;
clearFocusProbe();
setHardwareKeyboardAttached(value);
};
if (typeof window.__OPENCHAMBER_HARDWARE_KEYBOARD__ === 'boolean') {
adopt(window.__OPENCHAMBER_HARDWARE_KEYBOARD__);
}
if (bridgeStarted) return () => {};
bridgeStarted = true;
const handleNativeChange = (event: Event) => {
const detail = (event as CustomEvent<{ attached?: boolean }>).detail;
adopt(detail?.attached === true);
};
window.addEventListener('oc:hardware-keyboard', handleNativeChange);
return () => {
window.removeEventListener('oc:hardware-keyboard', handleNativeChange);
bridgeStarted = false;
};
};
/**
* Feed a native `keyboardWillShow` height in. Called by the Capacitor keyboard
* bridge (see `mobileNativeChrome`) on both platforms. An arriving event always
* settles the question, so it cancels any pending focus probe.
*/
export const observeNativeKeyboardHeight = (heightPx: number): void => {
if (hasNativeAnswer || !Number.isFinite(heightPx)) return;
clearFocusProbe();
setHardwareKeyboardAttached(heightPx > 0 && heightPx < SOFTWARE_KEYBOARD_MIN_HEIGHT_PX);
};
/**
* Report that an editor just took focus. If no keyboard event follows, nothing
* was presented — which means a hardware keyboard is attached.
*
* Deliberately one-directional within the window: only the SILENCE concludes
* "hardware". A real `keyboardWillShow` cancels the probe above, so a slow
* keyboard can never be misread.
*/
export const observeEditorFocus = (): void => {
if (hasNativeAnswer || typeof window === 'undefined' || typeof document === 'undefined') return;
// A soft keyboard already up sends no second `keyboardWillShow` — a refocus
// through it (the overlay-close keyboard restore) would look like silence.
if (document.documentElement.classList.contains('oc-keyboard-open')) return;
clearFocusProbe();
focusProbeTimer = window.setTimeout(() => {
focusProbeTimer = null;
setHardwareKeyboardAttached(true);
}, KEYBOARD_EVENT_GRACE_MS);
};
/** Drop the inferred state when the native bridge tears down. */
export const resetHardwareKeyboardDetection = (): void => {
clearFocusProbe();
if (hasNativeAnswer) return;
setHardwareKeyboardAttached(false);
};
export const isHardwareKeyboardAttached = (): boolean => hardwareKeyboardAttached;
export const subscribeHardwareKeyboard = (listener: () => void): (() => void) => {
subscribers.add(listener);
return () => {
subscribers.delete(listener);
};
};
export function useHardwareKeyboard(): boolean {
return React.useSyncExternalStore(
subscribeHardwareKeyboard,
isHardwareKeyboardAttached,
() => false,
);
}