Photos, Agenda and an inbox on the toolkit's grid

Three applications, all of them over the machine's own store, and all of them host-verified only. That last part is stated up front because it is the important caveat and it applies to all three.

Photos

A photo album: a grid of thumbnails, a full view with previous and next, albums, tags, captions, the capture date read out of EXIF, and search across all of those. It is side-loaded through the shop rather than built into the image.

Everything it knows is six ordinary collections created through the published store operations, readable by the Collections application like any other data. Membership and tags are rows rather than comma-separated fields, because a photograph can be in several albums and carry several tags, and the store is a relational database with no list-valued field. The bytes and the thumbnails are rows of their own so that reading an album's metadata never drags megabytes through the operation channel: thumbnails are read once at start and the grid decodes nothing, and an original is fetched only when it is opened.

Decoding happens in the application's own process rather than through the kernel's thumbnail operation. That operation caps a picture at 1 MiB and 2048 by 2048, which no camera has produced this decade, and it runs in the kernel's 256 MiB heap, shared with the window server. A process has a 2 GiB demand-paged heap, which is the right place for this. The library has no DCT-domain downscale, so a 24-megapixel frame does exist whole for a moment, as 72 MiB of RGB rather than 96 of RGBA; the picture is shrunk first and the small result rotated, so that buffer is the only large one and is dropped before anything else happens.

Importing means reading a folder of an SMB share, because that is the one way a file can arrive on this machine today. USB disks are enumerated and no operation reads a file from one. The browser has no download path. The HTTPS request operation returns its body as text and would corrupt a JPEG. The store's files table has no operation over it. The README says which of those is which rather than inventing a transport.

Agenda

Agenda speaks JMAP Calendars to the same Fastmail session the Mail application speaks JMAP Mail to, in the same envelope, and shows the result two ways: the days ahead grouped by day with all-day events first, and a month grid whose cells choose a day.

One Fastmail API token can carry both scopes, so a machine that has signed in to Mail already has the credential and Agenda uses it by name. Every request says which secret it wants and the kernel builds the header, so the token never passes through the application. A token that Fastmail accepts but that has no Calendars scope is the one failure the session document can distinguish, and it gets its own pane saying which scope is missing and where in Fastmail's settings to add it, rather than showing an empty week.

Opening is two round trips: the session, then calendars and events in one request chained by back-reference. The reply is kept whole in the store and read back at the next start, so the agenda is useful offline and a failed fetch leaves the last one on screen with the reason in the status line.

Recurrence is expanded on the machine rather than asked of the server, which is what makes the cached copy worth having. Daily, weekly, monthly and yearly rules with interval, count, until, byDay with and without ordinals, byMonthDay including negatives, and byMonth are expanded, and overrides can remove, move or retitle a single occurrence. The rules that are not handled - hourly, bySetPosition, byWeekNo, byYearDay, weeks not starting on Monday, non-Gregorian calendars - are refused at parse time with a reason the detail pane shows beside the event's first occurrence. That is less wrong than a partial expansion that looks right.

Time zones are rules rather than a database: the EU's, the United States', and a table of fixed offsets. Events carry a zone and the machine runs in UTC.

Mail's inbox, as a grid

Mail's inbox is rebuilt on the toolkit's grid rather than on its own list code - fixed columns, a fixed header over a scrolling body, row identity, paging, and dates a person can actually read rather than timestamps.

Doing it that way found four faults in the grid itself, which is the usual reward for making a second thing use the first thing. A row under a scroller was taking its widest cell's width as its height. The header gutter did not allow for the gap it brings with it. A focused row scrolled under the cursor instead of moving with the arrow keys. And a cell clipped its text instead of eliding it.

What is not built

None of this has run on the X1 or on any VM. Photos has 26 tests in its crate and passes the hosted and bare-metal halves of the applications check; Agenda and the grid work are the same shape of evidence. Each README's first hardware test says what to look at first, which is an admission rather than a plan.

Agenda does no incremental sync. Mail does not either, and the window is small enough that a refetch is the same single request, so that is a decision rather than an omission - but it will stop being the right one when the window gets longer.

There is still no way to get a file onto this machine except an SMB share.