Opening an item does not mark it read, and none of the page's keys work #11

New Issue

rays · 2026-09-20T07:24:20-07:00

rays commented

2026-09-20 07:24:20 -07:00

Two behaviours the page has and the native interface does not.

Opening an item is reading it. selectEntry calls markRead, so picking a row marks it read there and then. Natively a row can be opened, read and left, and it stays bold and unread until something else marks it. There is a detail to go with it: on the Unread tab the item you were reading is dropped from the list when you move on to the next one, not whenever a refresh next happens, and the row is redrawn where it stands rather than the list reloaded, so nothing vanishes from under the pointer. The failure is also rolled back — a flag that does not save puts the item back to unread and says so.

The keys. The page has Feedly's set, and none of them are here:

j n / k p   next and previous item
J / K       next and previous feed
o           play the selected item
m           mark it read or unread
s           pin it, or unpin it
v           open the original
Shift A     mark everything read
r           refresh
[           show or hide the feed list
Space       play or pause
left/right  back 15, forward 30
g then a d p l    All, Directory, Popular, Currently Listening
g then s    Settings
?           the list of them

None fire with Ctrl, Alt or Cmd held, so the system's own shortcuts still work, and the second key of a g pair only counts within a second and a half of the first.

On a Mac an app with a list and no keys is markedly worse than the web page it replaced, which is the whole point of the exercise going backwards.

Two behaviours the page has and the native interface does not. **Opening an item is reading it.** `selectEntry` calls `markRead`, so picking a row marks it read there and then. Natively a row can be opened, read and left, and it stays bold and unread until something else marks it. There is a detail to go with it: on the Unread tab the item you were reading is dropped from the list when you move on to the next one, not whenever a refresh next happens, and the row is redrawn where it stands rather than the list reloaded, so nothing vanishes from under the pointer. The failure is also rolled back — a flag that does not save puts the item back to unread and says so. **The keys.** The page has Feedly's set, and none of them are here: j n / k p next and previous item J / K next and previous feed o play the selected item m mark it read or unread s pin it, or unpin it v open the original Shift A mark everything read r refresh [ show or hide the feed list Space play or pause left/right back 15, forward 30 g then a d p l All, Directory, Popular, Currently Listening g then s Settings ? the list of them None fire with Ctrl, Alt or Cmd held, so the system's own shortcuts still work, and the second key of a g pair only counts within a second and a half of the first. On a Mac an app with a list and no keys is markedly worse than the web page it replaced, which is the whole point of the exercise going backwards.

rays added the bug label 2026-09-20 07:24:20 -07:00

rays referenced this issue from a commit

2026-09-20 08:26:06 -07:00

Opening an item reads it, and the page's keys (#11)

rays commented

2026-09-20 08:26:25 -07:00

Done in d68f1d0.

Opening an item reads it, including the Unread tab dropping the one you were reading when you move on rather than on the next refresh, and a failed write rolls back and says so.

The keys are the page's, with the 1.5s pair window and p/s meaning different things with and without a preceding g. They are UIKeyCommand (onKeyPress is iOS 17) and they hang off the hosting controller, not the one that owns it — SwiftUI's views hold first responder, so the chain starts inside that hierarchy and an override further up is never consulted.

Left unproven: whether a press arrives at all. The simulator drops key events unless something is focused, and running the same tests against Catalyst needs the runner to have accessibility permission it does not have here. KeysTests covers the map, which is where a typo silently loses a shortcut; the UI test is skipped with the reason written into it. Worth confirming by hand — if ? does nothing, the next step is registering through Catalyst's menu system, which would also put the shortcuts in the menu bar.

Done in d68f1d0. Opening an item reads it, including the Unread tab dropping the one you were reading when you move on rather than on the next refresh, and a failed write rolls back and says so. The keys are the page's, with the 1.5s pair window and `p`/`s` meaning different things with and without a preceding `g`. They are `UIKeyCommand` (`onKeyPress` is iOS 17) and they hang off the hosting controller, not the one that owns it — SwiftUI's views hold first responder, so the chain starts inside that hierarchy and an override further up is never consulted. **Left unproven:** whether a press arrives at all. The simulator drops key events unless something is focused, and running the same tests against Catalyst needs the runner to have accessibility permission it does not have here. `KeysTests` covers the map, which is where a typo silently loses a shortcut; the UI test is skipped with the reason written into it. Worth confirming by hand — if `?` does nothing, the next step is registering through Catalyst's menu system, which would also put the shortcuts in the menu bar.

rays closed this issue

2026-09-20 08:26:26 -07:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: rays/ipodderx-app#11