Ray Slakinski
d68f1d0d1d
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>
1.3 KiB
1.3 KiB