ios client for sourcehut. swiftui. http://git.krz.sh/krz/hutch.git/atom?h=main 2026-07-16T05:29:34+00:00 2026-07-16T05:29:34+00:00 Christian Cleberg hello@cleberg.net 2026-07-16T05:29:34+00:00 urn:sha1:6898bc3fc00decee7224895ea75908daf0f97f59 Three problems from manual testing. Opening a mailing list from More → Projects showed a blank screen, while the same tap on a project pinned to Home worked. handleTabNavigation reset the target path and appended to it two Task.yields later. When the target tab is already on screen — Projects lives under More — the reset starts an animated pop of the view the user is standing on and the appends land mid-animation. From Home the tab actually changes, so the More stack is quiescent and the appends land cleanly. Each case now builds its path and assigns it once, so SwiftUI gets a single diff with nothing to race. Destructive swipe actions made the row vanish and spring back while the confirmation was still up. role: .destructive makes SwiftUI perform the row removal on activation, which allowsFullSwipe: false does not prevent — the report was a tap, not a full swipe. These buttons only record pending state and wait for an answer, so they are plain buttons tinted red instead. Six sites: the two added here, plus trackers, pastes, and tracker ACLs and labels, which had the same flicker already. The artifacts upload control was invisible. It was declared as a toolbar item from a view that is a segment inside RepositoryDetailView's tab switch rather than its own navigation destination, so it never reached the navigation bar. It is a row in the list now, and also an action on the empty state — the overlay covers the list, and a repository with no artifacts is precisely the one that needs uploading. 2026-07-16T05:18:53+00:00 Christian Cleberg hello@cleberg.net 2026-07-16T05:18:53+00:00 urn:sha1:2514b58a96ccb73b4feea8f74a2367c72ba824c8 Swiping to delete made the row vanish and then spring back while the confirmation was still on screen. A destructive swipe action left to full-swipe performs itself on the gesture and animates the row away, but these actions only set pending state and wait for an answer, so the row returned when the data had not changed. allowsFullSwipe: false, which PasteListView already uses for exactly this confirm-then-delete shape. Both new swipes had the same omission. 2026-07-16T04:58:26+00:00 Christian Cleberg hello@cleberg.net 2026-07-16T04:58:26+00:00 urn:sha1:59622556deb4de7843faa493c8d5a6ef66591d91 createMailingList, updateMailingList, and deleteMailingList existed in the API but were never called, so lists could only be read. Editing needed a read first. InboxMailingListReference carries only id/rid/name/owner, so a settings sheet seeded from it would have offered an empty description and Public visibility, and saving would have blanked the real description and quietly changed who can see the list. The sheet now reads the current values and refuses to save until it has them. Clearing a description sends an explicit null via updateValue rather than a nil subscript assignment, which would drop the key and leave the old text in place. permitMime and rejectMime are left untouched rather than sent empty, which would wipe the list's mime filters. Edit and delete are gated on ownership: the subscriptions query that builds this view returns lists the user follows, which is not the same as lists they own. Non-owners keep the unsubscribe action instead. Deleting destroys the archive for everyone, so the confirmation says exactly that. 2026-07-16T02:33:59+00:00 Christian Cleberg hello@cleberg.net 2026-07-16T02:33:59+00:00 urn:sha1:b9ec80716ea015de5b6b31395fdc5ff03191398c * refactor: collapse duplicated request paths in SRHTClient Five request paths each repeated the token guard, header setup, status-code handling, and a ~35-line #if DEBUG logging block. The file carried that block five times over. Extract makeAuthorizedRequest, send, and encodedGraphQLBody, and route execute, executeAndCache, executeMultipartFiles, and performGraphQLRequest through them. executeMultipart is now the single-file case of executeMultipartFiles, which it already was byte for byte. 938 lines to 612, with one copy of the logging block. fetchText keeps its own guard: it is a GET to an allowlisted URL and must not run GraphQL error checks over what is usually a plain-text build log. One behavior change falls out. executeAndCache wrote the raw response to the cache before decoding, so a 200 carrying GraphQL errors was cached and then thrown. Routing it through performGraphQLRequest surfaces those errors first, so error payloads are no longer cached. * feat: edit and delete tickets updateTicket and deleteTicket both existed in todo.sr.ht's API but were never called, so a ticket could be filed and its status changed but its subject and body were frozen from the moment it was created, and it could never be removed. Edit opens a sheet seeded with the current subject and body. The input carries only fields that actually changed, so an edit cannot clobber a field the user did not touch, and Save stays disabled until something differs. Clearing the body sends an explicit null via updateValue rather than a nil subscript assignment, which would drop the key and silently leave the old body in place — the same trap fixed for repository descriptions in 7ffef07. Delete is destructive and irreversible, so it sits behind a confirmation dialog naming the ticket and pops the detail view on success. * feat: subscribe to and unsubscribe from tickets ticketSubscribe and ticketUnsubscribe existed in the API but were never called, so email notifications for a ticket could only be managed on the web. Ticket.subscription is null when the user is not subscribed, so the detail query now reads it and the menu reflects real server state rather than guessing. The toggle updates optimistically and reverts on failure, so the control never claims a subscription that did not take. Decoded into the private payload rather than TicketDetail, which is Codable and cached — adding a field there would have changed the cached shape and touched every optimistic-update construction site. * feat: subscribe to and unsubscribe from trackers trackerSubscribe and trackerUnsubscribe existed in the API but were never called. Tracker.subscription is null when not subscribed, so the state can be read rather than guessed. The read is a separate uncached query. The tickets query it sits beside is paginated and cached, and a per-user subscription has no business riding along in page payloads or being served stale from disk. Unsubscribe passes tickets: false, so leaving a tracker does not silently drop subscriptions to individual tickets the user opted into. * feat: unsubscribe from mailing lists mailingListUnsubscribe existed in the API but was never called, so the list of subscriptions was readable and nothing more. Scoped to unsubscribe. MailingList has no subscription field, unlike Ticket and Tracker, so per-list state is only knowable from the subscriptions query — which is exactly what builds this view. Subscribing would need a list the user is by definition not subscribed to, and sr.ht exposes no discovery API to find one (see SCOPE.md on hub.sr.ht), so there is nowhere honest to put that action yet. The row is removed optimistically and restored if the mutation fails. The confirmation says plainly that Hutch cannot resubscribe, since it cannot. * feat: manage todo and lists email preferences updatePreferences existed on both services but was never called, so these were web-only settings. The two services expose preferences/updatePreferences under identical names but with different fields — notifySelf on todo, copySelf on lists — and there is no shared preferences service, so both are read and written side by side. They load concurrently and one service being unreachable does not hide the other's toggle. These are server-side and apply beyond Hutch, unlike the @AppStorage toggles above them in Settings, so the footer says so and each toggle reverts if its mutation fails. * refactor: drop the memory-only cache path Two executeCached overloads existed with different return types and semantics: one doing stale-while-revalidate against the persistent cache with TTLs, the other only consulting the in-memory responseCache. The second was an easy thing to reach for by mistake, since the compiler picked it purely on argument labels. It turned out to be dead. All 38 call sites already used the TTL-aware overload, and the memory-only one was the sole caller of executeAndCache, so both are removed. Its doc comment promised refresh "via the onRefresh callback", which the signature has not had for some time. SRHTClient is now 569 lines, down from 938 before this branch. responseCache stays as the in-memory layer behind cachedPayload and the three view models that read it directly. * chore: bump to 3.6.0 and record Phase 1 MARKETING_VERSION 3.5.0 -> 3.6.0, build 87 -> 88. * fix: decode preferences responses on the main actor The module sets SWIFT_DEFAULT_ACTOR_ISOLATION = MainActor, so the response types are implicitly main-actor isolated and their Decodable conformances are too. Decoding straight from an `async let` used those conformances from a nonisolated context, which warns today and is an error in the Swift 6 language mode. Move each fetch into its own method and `async let` over those instead, so decoding stays on the main actor. This is what HomeViewModel.loadDashboard already does, and the concurrency is unaffected — the network work still overlaps, since execute suspends and frees the actor. 2026-04-14T00:06:54+00:00 Christian Cleberg hello@cleberg.net 2026-04-14T00:06:54+00:00 urn:sha1:a6ad2b9815d72575206bdca860eef9db850cdf1c Apply listRowBackground(Color.black) per row in AMOLED mode using ThemedRowStyle and themedRow() across Lists and Forms. Use themedList() for scroll/grouped backgrounds. Treat segmented and clear list rows with isAMOLED-aware listRowBackground where Color.clear was required. Removes reliance on UIKit appearance for list cells on iOS 16+. Implements: https://todo.sr.ht/~ccleberg/hutch/24 2026-04-02T03:20:43+00:00 Christian Cleberg hello@cleberg.net 2026-04-02T03:20:43+00:00 urn:sha1:eeb12de93c4f6fcc5e2f2d58c2061ce84f839cf7 2026-03-23T01:42:45+00:00 Christian Cleberg hello@cleberg.net 2026-03-23T01:42:45+00:00 urn:sha1:1f8b7a23529462c3c332753d33810b5c9f692bbc 2026-03-19T20:17:38+00:00 Christian Cleberg hello@cleberg.net 2026-03-19T20:17:38+00:00 urn:sha1:6ba4e967d5dfb5d3c7bb97a0f2662f3180595563