The chrome was designed for a phone and a tablet; the desktop is the surface you actually sit at #70

New issue

Open

opened 2026-07-31 12:27:15 +00:00 by aiko · 0 comments

aiko commented

2026-07-31 12:27:15 +00:00

Owner

Split out of #67 on 2026-07-31, which decided the narrow question and deliberately left the wide one here.

What `#67` settled, and what it did not

Settled: the desktop takes tablet-landscape on purpose. Onboarding is passed through once per device, the 640px measure on a filled ground is not wrong at 900px, and chrome-plan.ts keeps its two rows. Recorded in design § 3a. The 900px breakpoint against a 900×670 default window was resolved by moving the window to 1024×700 rather than by moving the breakpoint.

Not settled: the chrome itself. The two-layout table is the whole story of how this app handles size, and it was drawn from a design describing a phone and a tablet. The desktop was never a case in it — it is sorted into the nearest existing row. That was the right call for a setup screen seen once per device. It is not obviously right for the surface the operator sits at most.

The questions this ticket owns

Does desktop become a third layout, or is tablet-landscape genuinely right for the chrome as well as for onboarding? #67 answered this for § 3a only, and said so.
What does the chrome look like above 900px? The 640px measure was chosen for a tablet and has never been reasoned about for a monitor. There is a lot of horizontal room that nothing currently claims.
Is the decorationless transparent window right for every mode, or only for § 1b's pal? tauri.conf.json sets decorations: false for the pal's sake and there is one window, which is why #67's sibling had to draw a titlebar by hand on the onboarding branch. That is a workaround for a window shape chosen for a different mode.
What the three mount points mean for layout. <Live2D /> is mounted at three places in the tree, one per mode (App.tsx around :44, :160, :165) — the same structure #68 is about. A chrome redesign that ignores it will fight it.

Constraints any answer inherits

If a third layout is added, chrome-plan.ts is where it goes. Onboarding takes its size from that table and must not grow a constant of its own again (#49).
TABLET_LANDSCAPE_MIN_WIDTH is 900 and the comparison is >=. The default window is now 1024×700 and clear of it; anything that moves either number is touching two things.
The go-between is not involved. This is entirely the Receiver's shape.

Scope

Not v1. v1 is "the conversation works" on the three surfaces (#41), and the chrome is not what stops it working — a desktop sorted into tablet-landscape holds a conversation perfectly well. This is worth doing because the desktop is now a first-class surface and deserves to be designed for rather than sorted into a row, which is a different reason from anything on the v1 list.

Left ready-for-human: nothing here is buildable until there is an opinion about what the desktop chrome should be, and that opinion is not an agent's to invent.

denpa#67, denpa#49, denpa#68, design § 3a / § 3b / § 1b

Split out of `#67` on 2026-07-31, which decided the narrow question and deliberately left the wide one here. ## What `#67` settled, and what it did not Settled: **the desktop takes tablet-landscape on purpose.** Onboarding is passed through once per device, the 640px measure on a filled ground is not wrong at 900px, and `chrome-plan.ts` keeps its two rows. Recorded in design § 3a. The 900px breakpoint against a 900×670 default window was resolved by moving the window to 1024×700 rather than by moving the breakpoint. Not settled: **the chrome itself.** The two-layout table is the whole story of how this app handles size, and it was drawn from a design describing a phone and a tablet. The desktop was never a case in it — it is sorted into the nearest existing row. That was the right call for a setup screen seen once per device. It is not obviously right for the surface the operator sits at most. ## The questions this ticket owns - **Does `desktop` become a third layout, or is tablet-landscape genuinely right for the chrome as well as for onboarding?** `#67` answered this for § 3a only, and said so. - **What does the chrome look like above 900px?** The 640px measure was chosen for a tablet and has never been reasoned about for a monitor. There is a lot of horizontal room that nothing currently claims. - **Is the decorationless transparent window right for every mode, or only for § 1b's pal?** `tauri.conf.json` sets `decorations: false` for the pal's sake and there is one window, which is why `#67`'s sibling had to draw a titlebar by hand on the onboarding branch. That is a workaround for a window shape chosen for a different mode. - **What the three mount points mean for layout.** `<Live2D />` is mounted at three places in the tree, one per mode (`App.tsx` around `:44`, `:160`, `:165`) — the same structure `#68` is about. A chrome redesign that ignores it will fight it. ## Constraints any answer inherits - If a third layout is added, **`chrome-plan.ts` is where it goes.** Onboarding takes its size from that table and must not grow a constant of its own again (`#49`). - `TABLET_LANDSCAPE_MIN_WIDTH` is 900 and the comparison is `>=`. The default window is now 1024×700 and clear of it; anything that moves either number is touching two things. - The go-between is not involved. This is entirely the Receiver's shape. ## Scope **Not v1.** v1 is "the conversation works" on the three surfaces (`#41`), and the chrome is not what stops it working — a desktop sorted into tablet-landscape holds a conversation perfectly well. This is worth doing because the desktop is now a first-class surface and deserves to be designed for rather than sorted into a row, which is a different reason from anything on the v1 list. Left `ready-for-human`: nothing here is buildable until there is an opinion about what the desktop chrome should be, and that opinion is not an agent's to invent. ## Related `denpa#67`, `denpa#49`, `denpa#68`, design § 3a / § 3b / § 1b

aiko added the

ready-for-human

labels

2026-07-31 12:27:15 +00:00

aiko referenced this issue

2026-07-31 14:33:58 +00:00

Onboarding was designed for mobile only, so the desktop is a tablet by default #67