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:
1 parent
6cad632a0c
commit
d74fea4905
12 files changed
+640
-88
No files matched your search
@@ -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.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in new issue
Block a user