In the simulation a tap on a device chooses it and opens its menu where
the finger was; the three-dot button is gone there, the long press stays.
The context menu moves in from the surface's edge instead of being cut off.
Undo and redo show drawn arrows: the characters took whatever font the
device had and looked squashed on an iPad (the buttons measured 44 x 44 at
every width; the size was not the cause).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The focused rectangle or text shows 44 px handles on its focus band: corners,
and the middles of long enough sides; on an item smaller than two targets only
the bottom right one, outside its corner. A text gets a grip above its top
left corner, since its middle is the field typed into. The three-dot button
moves above the top right corner; grip and button step aside at the surface's
edge. A tap on a handle is one on what lies under it, a long press opens the
menu, a second finger zooms. WebKit hands a tap's end to the handle despite
the capture, so the handle passes its events on.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A tap on a device in the simulation now only chooses it; its three-dot
button (or a long press) opens what Java's click opened: the desktop, and
newly a switch's SAT table and a home router's NAT table, beside each
card's data exchange.
The desktop, the tables and the data exchange are no windows in the
window any more but the simulation's sheet (SimulationSheet), after the
dashboard's AppSheet: below the toolbar to the bottom, a head with icon,
title, who else has it open, see-through and close. One at a time — it
covers the surface. It stays over a return to the design with the program
open on a desktop; a sheet whose device was removed closes. See-through
fades the body (0.55) and keeps the head; the choice is kept in the
browser. Java opens these as movable windows, several at once, with a
click; named in CHANGES.md.
Tests open through the menu (showFromMenu, showDesktop in editorPage.ts).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Moving a device, moving or resizing a documentation item went into the
shared document at every pointer move: 59 updates a second, each leaving
about 18 bytes of history (M4 on test-filius). Now the editor keeps the drag
while it lasts, shows it itself and tells the others through the awareness
(moving, at most every 50 ms, the end at once), and writes it once when it
is let go. A drag the browser cancels or a second finger turns into a pinch
is written where it is; WebKit sends a second pointerdown for the first
finger when another comes, which had lost the drag.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The touch test runs in Chromium on the desktop and in WebKit as an iPad
(810x1080 and 1080x810): the acceptance of F4 as a script ("zwei
Rechnernetze" built anew by finger, set up and pinged across), two fingers
zoom the surface and never the page (M7, without a frame), every action
without a right click, every target at least 44 px. Real gestures: CDP in
Chromium, WebKit's own Input.dispatchTouchEvent through Playwright's
in-process connection (Playwright pinned to 1.62.1). A dragged finger holds
still before it is lifted, or Chromium takes it for a fling.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
julian.kiedaischandClaude Opus 5.5