selectEntry in the page calls markRead, so picking a row reads it. Natively
an item could be opened, read and left, and it stayed bold. With it comes
the detail that would have been missed by guessing: on the Unread tab the
item you were reading is dropped when you move on to the next one, not
whenever a refresh next comes along, so nothing vanishes from under the
pointer mid-click. A flag that does not save rolls back and says so, where
the page toasts.
The keys are Feedly's set, from player.ts: j n and k p, shift J and K, o m
s v, shift A, r, [, space, the arrows, g then a d p l or s, and ? for the
list of them. The pair window is the page's second and a half, and p and s
mean different things with and without a g in front, which they do there
too.
They are UIKeyCommand rather than SwiftUI's onKeyPress, which is iOS 17,
and they hang off the hosting controller rather than the controller that
owns it: SwiftUI's views hold first responder, so the chain starts inside
that hierarchy and an override further up is never consulted.
What is tested is the map, in KeysTests -- that p is Previous alone and
Popular after g, that every mapped key is registered, that the window is
1.5s -- because a wrong letter there loses a shortcut silently. What is not
tested is whether a press arrives at all: the simulator drops key events
unless something is focused, and running the same tests against Catalyst,
where the keyboard is the point, needs the runner to have accessibility
permission it does not have here. That test is skipped with the reason
written in it rather than deleted or left red.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ipx on a wide screen is the feed list down the left, the item table across
the top right, and the item you are reading underneath it, with a bar
between them. The native interface pushed the item over the list instead,
which is what the page does under 820px and right there, but on a Mac it
meant losing the list to read one item and navigating back. The table was
wrong too: the page has columns that each sort, and this had a stack of
rows with the same facts run together underneath the title. Both now follow
the width, and at the same 820px the page draws the line at.
Sorting a column asks the server, as the list already did. Sorting the rows
on screen would only order the fifty that arrived.
The wash (#12) drew straight seams down the window and was loud enough to
make the selected row read as bright magenta. Each gradient had been sized
into a box and then moved, and a box has edges; they fill the view and are
placed by their centre now. And they were composited with plusLighter,
which adds -- the stylesheet layers them with ordinary alpha, so its values
are for colour sitting on what is behind it rather than added to it, and
three of them added came out far brighter than Glass has ever looked in a
browser. There was a wash per pane as well, so two met at the split and the
join was another seam; there is one now, for the window.
A SwiftUI Table with a sort order needs a comparator on every column -- a
mix of sortable and plain does not compile -- so the status column sorts by
read rather than being the one that cannot.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Pinned tab was not filtering. It sent filter=pinned, and Filter::parse
in db.rs knows unread, downloaded, flagged and in_progress and falls
through to All for anything else -- so the tab returned every item and
looked like it had worked. The column is still named flagged, for what it
was before the interface called it pinned, and the page had this right all
along.
Currently Listening was worse in kind. ipx has filter=in_progress for
exactly it: started past the first few seconds, short of the 90% the UI
calls finished, measured against the length this person's player reported
where there is one. The client asked for everything and trimmed the fifty
rows it happened to receive, so the view showed whichever started episodes
were near the top of the library, left out the rest, and counted wrong.
Both came of writing the filter names from the interface's words instead of
reading what the server parses.
The tests now assert what each filter means rather than how many rows it
returns -- every unread row unread, every downloaded row with a file, every
pinned row pinned, every in-progress row started -- because the failure
here was a full page of entirely plausible rows, which no count would have
caught. Pinned also has to match fewer than everything, which is the shape
the bug took.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Each is named in the toolbar's menu rather than hidden behind one button
that says "page": reaching Settings here should be no harder than in a
browser. Admin appears only for an admin, because the server sends that
page to admins alone and a link for anyone else leads to a refusal.
Settings, the directory, Popular and OPML are dialogs the page opens by
name rather than routes of their own, so they are reached by calling them
once it has loaded -- prefsModal(), opmlModal(), selectFeed(':directory').
Asking a moment after the load avoids racing the page wiring them up. The
admin page is a real route and just loads. Asking for the screen already
showing runs the script without reloading, or the page would reload to sit
exactly where it already was.
This is a decision as much as a change, and worth writing down: the goal
was never a native app with no web view in it. These screens are
form-heavy, rarely opened, admin-gated in places, and they work. Rewriting
them would have been the largest part of the job for the smallest return.
The test opens the menu, chooses Settings, and looks for the page's own
dialog, so a menu that opens the page but not the thing asked for fails
rather than passing. It also found that the menu had no accessibility
label, which it should have had anyway.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The reading pane: the item, its files with play, download and delete, read
and pin in the toolbar, a link to the original, and the notes.
The notes are a web view, deliberately. They are feed-supplied HTML that
ipx has already run through ammonia, and there is no good native renderer
for that -- NSAttributedString(html:) is slow, single-threaded and ugly,
and writing a real one is a project. So this carries only the notes, with
just enough stylesheet to belong to the app: the system font at body size,
the label colours, links in the accent. Nothing else is imposed, because
the markup is the publisher's. A link opens in Safari rather than inside
the view, where it would replace the notes with somebody's website and
leave no way back.
Deleting asks first, and says when the file is shared: one file serves
everyone reading the feed, so removing it is not a private act.
Two goes at the navigation. A row with a selection binding on the list
highlighted and went nowhere -- the binding takes the tap before the link
sees it. Without the binding, NavigationLink(value:) with a matching
navigationDestination still pushed nothing and gave no reason, so the link
carries its own destination now, which has nothing to get wrong.
Fourteen tests pass. The new one opens an item and looks for its notes, its
delete button and its read control, so a pane that renders empty fails
rather than passing quietly.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The lists are native now, and the page is a button in the toolbar: it is
still where signing in happens, and it is still the whole of settings, the
admin page, the directory and OPML, which were never going to be rewritten.
LibraryStore holds a page of items and asks for the next, because the
sorting, filtering and searching are the server's work and ten thousand
items have no business being in memory to be sorted here. Read and pinned
are set locally and sent after, as the page's readWrites map does and for
the same reason: a list asked for before the write lands answers with the
old state, which put the dot back on an item just read.
The interface follows the account's light or dark rather than the phone's,
and defaults to dark when nobody has chosen, because that is what ipx's own
theme.ts does. Following the system instead put a light list in front of a
dark page. preferredColorScheme was not enough on its own -- inside a
hosting controller it did not reach the hierarchy -- so the style is
overridden on the controller, which also carries to the page presented over
it.
The sidebar had to be broken into sub-views: the whole list in one
expression was more than the type checker would work through, and it said
so rather than compiling it.
Tested against the real library, 135 feeds and eleven thousand items, and
the playback test now drives the native row rather than the page's button.
Thirteen pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The first native surface, and the one that settles how the rest will look.
Glass.swift is not a port of the stylesheet. ipx's Glass is already an
approximation of what UIKit gives away -- panels are a 70% colour under
blur(24px) saturate(180%) with an inset top highlight, which is a material,
and the palette names Apple's own colours in its own comments. So where the
CSS had to write #409cff in dark and #0055aa in light, because no single
blue clears AA over the wash, this asks for the system blue and gets both.
Only the wash keeps its hex values: there the colour is the design and
there is no system equivalent to ask for.
PlayerBarView draws what Playback knows, and Playback is the same object
the lock screen and the remote commands drive, so all of them agree without
anything being kept in step by hand. Back 15 and forward 30 match the page
and the lock screen, so every way of skipping moves by the same amount.
Seeking waits for the finger to lift rather than sending a stream of seeks
at a player still answering the last one.
The page's own bar is hidden rather than left to sit under ours. Its play
buttons still work -- they post to the host either way -- but two bars for
one player would be two sets of buttons disagreeing about what is playing,
and only one of them is what CarPlay will be driving.
One test had to be rewritten rather than the code: it asserted that one of
the fixture's two episodes had a file, which stops being true the moment
the event test asks the daemon to scan. The daemon is shared and keeps what
earlier tests did to it, so the assertion now asks what the downloaded
filter means instead of how many things match it today. Thirteen pass,
twice over the same accumulated state.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Everything native needs this first, and it is worth having whatever happens
to the rest: a CarPlay browse tree is built from exactly these calls.
API covers what a client reads and writes -- feeds, entries with the
server's own paging, filtering, sorting and search, read and pinned,
position, read-all, download, delete, fetch -- and APIModels is what ipx
sends, with the server's field names kept so a type here can be checked
against web.rs without translating first. It sends nothing of its own to
authenticate: ipx decides who is asking by cookie and CookieBridge keeps
HTTPCookieStorage in step, which is the same property that lets a plain
<audio src> work.
Events reads /api/events with URLSession's byte stream, so there is no new
dependency. An event this build has never heard of decodes as .other rather
than throwing, because a new one on the server must not stop the stream. It
reconnects with a backoff: a deploy closes the stream cleanly and should be
picked straight back up, a daemon that is down should not be hammered.
Library is gone, folded into API. Two clients writing positions was one too
many, and the page's forwarded beacon no longer carries a path: it asks the
host to save, and the host uses its own clock, which is the only one not
stale when the web view has been frozen in the background.
The tests run against the browser suite's fixture daemon rather than canned
JSON, because the shapes being decoded are the server's and a fixture would
only prove it matches itself. Thirteen pass, including a live scan reported
over SSE and the playback round trip, which still works after the move.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
