| Age | Commit message (Collapse) | Author |
|---|
|
cal9 kept an event in a panel and a day in another, with the state that
implies: a selection, a picked day, rectangles for the buttons on it,
and a hundred-odd lines to draw it. Opening a window instead deletes all
of that rather than tidying it away. Clicking an event opens cal9 -v
event, clicking a day opens cal9 -v day, and cal9 is three grids again.
The event window earns being cal9 rather than pim/showwin: it carries
Accept, Tentative and Declined, lit to show where you stand, and only
when the calendar's ctl says it can rsvp. cal9 -v invite is a form that
writes the calendar's new file in the tree's key: value form, so the
composer knows nothing about iCalendar either.
datepick is a program rather than a widget so anything can use it:
pim/agenda -d `{datepick}
-t asks for a time as well, in stages, because a grid of ninety-six
five-minute slots is not something you want to aim at. A window started
from wctl has nowhere useful to print, so -o and -s hand the answer back
by file or by snarf; the invite form spawns it that way and fills the
field when it returns.
An event you have not answered draws pale, so a glance at the week says
what is still waiting.
Move and Resize are gone from the menus: rio owns the border and does
both, better. Compact is one item showing whichever state you are not
in.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|
"go build ./cmd/x" writes the binary to the current directory, not to
bin/, so pim/caldavfs and gui/spike were showing up as new files a
stray "git add ." would have committed. Anchored with a leading slash
so a source file of the same name deeper in the tree still counts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|
A calendar as a file tree, and tools that only know the tree:
events/date/yyyy/mm/dd/hhmm-summary as lived
events/uuid/<uid>/ as stored
ctl query alarm changed
lib/cal owns all of that. A backend supplies events and, where its
protocol allows, takes changes back -- six methods. cmd/icalfs is the
first: it reads .ics files from a directory and nothing else, because
fetching is rc/fetch's job and hget already exists. That keeps
net/http out of the binary and makes a subscribed calendar and a local
one the same thing.
The tools are rc on purpose. If the tree needs a compiled program to be
useful, the tree is the wrong shape. Three things were added to the
tree because the rc port needed them: a path from an occurrence to its
event, epoch seconds beside RFC3339, and a numeric slot for all-day
events so test(1) can compare it.
ctl reports caps, so a tool can say "read only" instead of trying and
failing. A published .ics is read only: nowhere to PUT, and no
METHOD:REQUEST to reply to. CalDAV would be read write rsvp schedule,
and that is the next backend.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
