Zooming left the page filling four fifths of the window, and less as the
zoom went up: at 1.6 it sat in the left three fifths with the rest of the
window empty.
body carried width:calc(100%/zoom). Under CSS zoom a percentage already
resolves against the containing block in the zoomed element's own units,
so 100% is the full width and dividing it again shrank the page by the zoom
a second time. A block fills its container without being told to, so the
declaration is gone. Viewport units are the exception -- dvh does not know
about zoom -- which is why the height still has to be divided back out.
Measured at 1.25, 1.6 and 2: body is exactly the window's 2275 by 1427 in
each, and the document overflows by nothing in either direction. The first
time round only the overflow was checked, which a page that under-fills
passes just as happily as one that fits.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ipx's page is sized for a phone and for a browser window. On a Mac, where
the window is often two thousand points across, it reads small -- measured:
a 2275 by 1427 point window, a 14.5px body font, about 150 characters to a
line. It is right everywhere else, so this is the shell's to fix and not a
text size for ipx to carry.
It scales with CSS zoom on the body, at 1.25 to start, with Cmd-plus,
Cmd-minus and Cmd-0 to change it. The page's own shortcuts are single keys
and ignore a modifier, so they do not collide, and iOS stays at 1.
Not WKWebView.pageZoom, which was tried twice. It scales what is drawn but
leaves the layout box the size of the window: measured, innerHeight said
1141 while html{height:100%} still resolved to 1427, so ipx's full-height
page -- body is 100dvh -- laid itself out at the window's height and was
then scaled past the bottom of it, spilling off the right edge with its
toolbar clipped. CSS zoom is part of layout, so the page measures itself
correctly; body's own width and height are divided back out because its
containing block is not zoomed.
Verified rather than assumed: the toolbar measures 52px with the style off
and 64px with it on, a ratio of 1.24, and the document overflows its
viewport by nothing in either direction.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A Catalyst app draws its iPad interface at 77% unless it says otherwise,
so everything on the Mac was smaller than it should have been.
UIDesignRequiresCompatibility: false asks for the Mac idiom and true size.
ARCHS is pinned to arm64 for macOS: the default is a universal binary, and
the x86_64 half is weight nothing here will run. It was never running under
Rosetta -- the arm64 slice was always the one in use.
There is no zoom command. A pair was tried and taken out again: pageZoom
only works on a document that scrolls, and ipx's page is a fixed viewport
-- body is height:100dvh with overflow hidden -- which WebKit resolves
against the unzoomed window, so the page laid itself out at the wrong size
and was then scaled, spilling off the right edge with its toolbar clipped.
Text size belongs to the page, which owns its own layout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The 2004 icon, from ipodderx-rs's apple-touch-icon.png, which at 180px is
the largest square copy that survives anywhere -- so the sizes above it are
upscaled and soft, and a real 1024px original would be worth having if one
turns up.
Every entry in the icon set gets its own file even where two are the same
pixels, because the asset compiler collapses entries that share a filename
and the first attempt produced an icns with four of the ten sizes.
tools/install-mac.sh builds Release for Catalyst and replaces the copy in
/Applications. It quits the running app first, or the replacement is the
one still in memory, and it sets DEVELOPER_DIR rather than relying on
xcode-select, which on this machine still points at the command line tools.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
xcodegen writes it from project.yml on every generate, so keeping it in git
gives the same facts two homes and a diff every time the yml changes. The
.xcodeproj is ignored for exactly this reason.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A shell around the ipodderx-rs web UI whose audio is played by the host
rather than the page, so it carries on with the screen locked and a car can
control it. The page's half of the bridge is web/src/native.ts in
ipodderx-rs (#45): it replaces the playback surface of the page's media
element with one that posts here, so player.ts is unchanged and the player
bar, the row buttons and the keyboard shortcuts work as they always did.
Playback, Library, Bridge and CookieBridge never touch a view, which is
what makes a CarPlay scene a later addition rather than a rewrite, and what
lets the same target build for Mac Catalyst with no conditional code:
AVAudioSession, MPNowPlayingInfoCenter and the remote commands all exist
there. The Mac gets media keys and Now Playing; it has no CarPlay and no
lock screen, so it is a convenience rather than the reason for any of this.
Authentication is the web view's. ipx decides who is asking by cookie --
ipx_session, and CF_Authorization from Cloudflare Access in front of the
tunnel -- and its auth layer was written so a plain <audio src> would work,
which is why the player needs no API of its own. CookieBridge keeps
HTTPCookieStorage in step with the web view's store and hands them to each
asset.
Named ipodderx-app, not -ios: native.ts already carries the branch for an
Android host, and the iOS project is one directory rather than the repo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
