ai/byre
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 10 Wiki Activity

font size setting

Browse Source
This commit is contained in:
Ian Gulliver
2026-10-20 19:32:27 -07:00
parent f2188c53eb
commit adb9424e66
9 changed files with 95 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/operations.md
+1 -1
View File
@@ -176,7 +176,7 @@ Clients reach byre over HTTP/2 on its tailnet node.
**Installing.** A release is installed from its disk image into `/Applications` (see "Releases") and updates itself (`docs/macos.md`, "Updates"). A deploy installs its build there the same way (see "Releases"). A build from a checkout can also run from where it was built, `open mac/.build/Byre.app` in the worktree that built it, after quitting the running app (`pkill -x Byre` quits every running copy). Every build shares the bundle identifier `run.fc.byre.mac` and the same store, so any build reconnects to the servers the last one saved, switched between with the window's server picker in its compact toolbar, which has the Away button at its right end (see "Away"). Closing the window leaves the app running for notifications; ⌘Q quits it.
**Storage.** The app keeps three kinds of record in SwiftData (`mac/Sources/Byre/Persistence.swift`): each saved server's origin and window colour, when each task was last selected, and composer and answer drafts as JSON, one record per server and login (`docs/macos.md`, "Persistence" and "Drafts"). The store is `~/Library/Application Support/run.fc.byre.mac/byre.store`, with its `-shm` and `-wal` files and CloudKit's working files beside it in that directory; the app isn't sandboxed, so it names its own file rather than SwiftData's default `default.store`, which every unsandboxed app shares. The store syncs through the iCloud private database of container `iCloud.run.fc.byre.mac`, in CloudKit's Production environment (`com.apple.developer.icloud-container-environment` in `mac/byre.entitlements`). Production never creates fields itself: a record carrying an attribute its schema lacks is rejected, and that one rejection stalls every later upload from that Mac (its `ANSCKEVENT` table shows exports failing with `CKErrorDomain` 2), until the app relaunches after the schema is fixed. The app never writes to Development either, so a change to the SwiftData models must be added there by hand before it is deployed or released: `xcrun cktool export-schema --team-id <team> --container-id iCloud.run.fc.byre.mac --environment development --output-file <file>` (`<team>` is `TeamIdentifier` in `security cms -D -i mac/byre.provisionprofile`), add each new attribute to its `CD_<Model>` record type as `CD_<attribute>` (`Int` is `INT64 QUERYABLE SORTABLE`), `xcrun cktool import-schema` the file back to Development, then Deploy Schema Changes in the CloudKit console; `export-schema --environment production` shows what Production has, and `mac/package.sh` refuses to build while it lacks a model attribute. `cktool` needs a management token saved with `xcrun cktool save-token --type management --method file` (the console's Tokens & Keys page makes one). The CloudKit console (icloud.developer.apple.com, the container, Production, Private Database, zone `com.apple.coredata.cloudkit.zone`) shows the records. The app watches every finished CloudKit setup, import and export (`NSPersistentCloudKitContainer.eventChangedNotification`, in `Servers` in `mac/Sources/Byre/Startup.swift`) and keeps the latest of each kind: succeeded, or failed with the error (for a partial failure, the first record's error and how many records failed), and when. Its sync state is the newest failed one while any kind's latest failed, so a successful import doesn't hide exports that still fail, and otherwise the newest. A failure is logged with the error in the clear, which CoreData's own log lines redact. The Settings tab shows the state under iCloud sync, a failure in the danger colour, and the app reports it to every server it is connected to with `PUT /api/clients/sync` (`ClientSync`: `ok`, `error`, `at`), on each change and each time its `/api/clients/connect` WebSocket connects or reconnects, so a report lost while the server was unreachable is sent again; the server keeps it in the client registry and shows it as the client's `sync` in the status (see "Status"), so the Status tab's Clients table and `list_clients` show a Mac whose sync is failing. Deleting the local files while the app isn't running makes the next launch download the records again from iCloud; deleting the records in the console as well starts from the connection screen. Pasted images stay in memory and are dropped on Forget Server and quit. The app logs through `os.Logger`: `log show --last 10m --predicate 'subsystem == "run.fc.byre.mac"'` prints it.
**Storage.** The app keeps four kinds of record in SwiftData (`mac/Sources/Byre/Persistence.swift`): each saved server's origin and window colour, when each task was last selected, composer and answer drafts as JSON, one record per server and login (`docs/macos.md`, "Persistence" and "Drafts"), and the user's font size (`PrefsRecord`, see "Font size" in `docs/macos.md`). The store is `~/Library/Application Support/run.fc.byre.mac/byre.store`, with its `-shm` and `-wal` files and CloudKit's working files beside it in that directory; the app isn't sandboxed, so it names its own file rather than SwiftData's default `default.store`, which every unsandboxed app shares. The store syncs through the iCloud private database of container `iCloud.run.fc.byre.mac`, in CloudKit's Production environment (`com.apple.developer.icloud-container-environment` in `mac/byre.entitlements`). Production never creates fields itself: a record carrying an attribute its schema lacks is rejected, and that one rejection stalls every later upload from that Mac (its `ANSCKEVENT` table shows exports failing with `CKErrorDomain` 2), until the app relaunches after the schema is fixed. The app never writes to Development either, so a change to the SwiftData models must be added there by hand before it is deployed or released: `xcrun cktool export-schema --team-id <team> --container-id iCloud.run.fc.byre.mac --environment development --output-file <file>` (`<team>` is `TeamIdentifier` in `security cms -D -i mac/byre.provisionprofile`), add each new attribute to its `CD_<Model>` record type as `CD_<attribute>` (`Int` is `INT64 QUERYABLE SORTABLE`), and each new model as a `CD_<Model>` record type shaped like the others (`CD_entityName`, the `___` system fields and the grants), `xcrun cktool import-schema` the file back to Development, then Deploy Schema Changes in the CloudKit console; `export-schema --environment production` shows what Production has, and `mac/package.sh` refuses to build while it lacks a model attribute. `cktool` needs a management token saved with `xcrun cktool save-token --type management --method file` (the console's Tokens & Keys page makes one). The CloudKit console (icloud.developer.apple.com, the container, Production, Private Database, zone `com.apple.coredata.cloudkit.zone`) shows the records. The app watches every finished CloudKit setup, import and export (`NSPersistentCloudKitContainer.eventChangedNotification`, in `Servers` in `mac/Sources/Byre/Startup.swift`) and keeps the latest of each kind: succeeded, or failed with the error (for a partial failure, the first record's error and how many records failed), and when. Its sync state is the newest failed one while any kind's latest failed, so a successful import doesn't hide exports that still fail, and otherwise the newest. A failure is logged with the error in the clear, which CoreData's own log lines redact. The Settings tab shows the state under iCloud sync, a failure in the danger colour, and the app reports it to every server it is connected to with `PUT /api/clients/sync` (`ClientSync`: `ok`, `error`, `at`), on each change and each time its `/api/clients/connect` WebSocket connects or reconnects, so a report lost while the server was unreachable is sent again; the server keeps it in the client registry and shows it as the client's `sync` in the status (see "Status"), so the Status tab's Clients table and `list_clients` show a Mac whose sync is failing. Deleting the local files while the app isn't running makes the next launch download the records again from iCloud; deleting the records in the console as well starts from the connection screen. Pasted images stay in memory and are dropped on Forget Server and quit. The app logs through `os.Logger`: `log show --last 10m --predicate 'subsystem == "run.fc.byre.mac"'` prints it.
## Screen and app control