Chapters as rows, in two views, in their own colours

Three things Marc asked for, and one of them turned out to be the hinge
the other two hang from.

**A chapter is a row like any other.** Same grip, same drag, same place
in a hand-made arrangement as a note or a separator. That needed notes
and chapters numbered from *one* counter: numbered separately they are
two sequences that cannot be interleaved again, and a chapter dragged
between two notes springs back to the top. Positions therefore have to be
named rather than read off an array index, so POST /notes/reorder now
takes `positions: [{id, order}]` beside the older `ids`, and chapters
have a reorder route of their own.

**Two ways for a chapter to open**, chosen per account beside the
typeface, for the same reason that one lives there: it is a choice about
how your own notes are laid out and it should follow you to the phone.
Beside the list, its notes in a further column the way OneNote lays out
pages — the notebook's own list carrying on to the left, chapter rows and
all. Or unfolded under the chapter's own row, indented against a rule in
its colour. A phone has room for neither and fills the list instead, with
a way back, which is what it did before there was a choice.

**Its own colour**, from eight named ones rather than the full palette:
the point of chapters is that they are different places, and twenty
near-identical blues do not help anyone tell them apart.

The colour is validated on the way in — it is written by a browser, so
only a plain #rrggbb gets through and anything else becomes no colour.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
marcandClaude Opus 5 committed 2026-08-12 14:20:14 +02:00
1 parent 6cad632a0c
commit d74fea4905
12 files changed
+640 -88

No files matched your search

+32 -3
View File
@@ -432,7 +432,7 @@ docker compose -f docker-compose.dev.yml up -d --build # must be running
| `conflict` | 10 | a late write wins but the state it buries survives as a version |
| `export` | 21 | the downloaded bytes are real Markdown, ZIP and PNG, unpacked and read back |
| `organise` | 52 | a hand-made order survives a search; separators hold their place; a note exported and imported comes back whole |
| `chapters` | 13 | a note filed into a chapter leaves the notebook's list, and removing the chapter gives every note back |
| `chapters` | 21 | a note filed into a chapter leaves the notebook's list, and removing the chapter gives every note back |
| `offline` | 17 | a cold page load with the network off still opens notes and searches them — and a note made, written and drawn on offline arrives whole once there is a connection |
| `sync` | 7 | a PDF written on one device — document, drawing and pinned notes — reaches a second one, which can find it by its contents without opening it |
@@ -483,7 +483,7 @@ the left edge. Centred, the same leftover space reads as two margins and needs n
explaining.
**The typeface is a per-account setting** (Account → Profile): serif, sans or
mono. On the account rather than in the browser, because a choice about how your
mono. How a chapter opens is chosen there too, for the same reason. On the account rather than in the browser, because a choice about how your
own notes are set should follow you to the phone rather than be made again on
every device. The server accepts those three values and drops anything else —
that column is written by a browser, so it is an input like any other.
@@ -971,7 +971,36 @@ Three rules that keep the two levels honest:
A note made while a chapter is open is filed there without being moved. A chapter
is named when it is created, unlike a separator: a separator is a line and reads
perfectly well unnamed, while an unnamed chapter is a row nobody can tell from
the next one.
the next one. Each can be given **its own colour** — the point of having chapters
is that they are different places, and eight named colours tell them apart where
twenty near-identical blues would not.
### How a chapter opens
Two ways, chosen per account under Account → Profile, beside the typeface and for
the same reason: it is a choice about how your own notes are laid out, and it
should follow you to the phone.
- **Beside the list** — its notes in a further column, the way OneNote lays out
its pages. The notebook's own list carries on to the left, chapter rows and
all.
- **Under the chapter** — its notes unfold in place, indented against a rule in
the chapter's colour.
A phone has room for neither. There the chapter fills the list and the header
button becomes a way back out, which is what it did before there was a choice.
### A chapter is a row like any other
Chapters sit at the same level as notes and separators: same grip, same drag,
same place in a hand-made arrangement. That takes **one counter for both** in
`toArrangement` — numbering notes and chapters separately would leave two
sequences that cannot be interleaved again, and a chapter dragged between two
notes would spring back to the top.
Positions therefore have to be *named* rather than taken from an array index,
which is why `POST /notes/reorder` accepts `positions: [{id, order}]` beside the
older `ids`, and why chapters have a reorder route of their own.
---