@yuneta/gobj-ui 7.23.195 → 7.23.197

package/README.md

@@ -2003,16 +2003,17 @@ columns**, each in its declared `order`, with the storage composed underneath
 the qualified id, the fkey to the parent, the place among the siblings, and the
 versions that publish the change.
 
-**The versions are the point, not a detail.** `topic_version` is what publishes
-a change of a topic's columns: leave it and the persisted `topic_cols.json`
-masks the whole edit — the restart succeeds and nothing moved. `schema_version`
-is what publishes the schema as a whole ("the stored one wins on ties, and the
-incoming one has to be strictly newer to take over", `c_treedb.c`), and raising
-it is safe: re-projection from C compares `c_schema_version`, the version of
-the **literal**, precisely so that an edit made here survives every start until
-a newer literal arrives. So **every write carries both** and the operator is
-never asked to remember either. The banner in the column screen is for the case
-where something *else* wrote the topic and left its version alone.
+**An edit here is a draft** (7.23.196, with the SDK's M36 design). A write moves
+no version and reaches no treedb. The HOST publishes it with `C_TREEDB`'s
+`save-schema`, which raises the `topic_version` of each topic that changed
+(the one that regenerates `topic_cols.json`) and the `schema_version` (the one
+that makes the schema file win over the literal), once, and puts it in use with
+`apply-schema` and a restart of the owning yuno. Until 7.23.195 every write
+here raised both numbers, so an edit half made was already the schema of the
+next start. The topic list marks what this session wrote and has not saved,
+and the column screen says so in a banner; the host sends `EV_REFRESH` after a
+save, and the reload forgets the drafts. The export (C literal and JSON) warns
+while there are drafts: the literal carries the versions a save publishes.
 
 What the screens offer:
 
@@ -2083,7 +2084,37 @@ The logic is pure and tested apart from the view: `schema_model.js` (the three
 lists regrouped — grouping follows the **fkey**, not a split of the qualified
 id on `.`, which works right up to the first name that carries one),
 `schema_validate.js`, `schema_descs.js`, `schema_to_c.js`, `schema_import.js`,
-`schema_flags.js`, `schema_write_options.js`. Since 6.1.0.
+`schema_flags.js`, `schema_write_options.js`, `schema_to_diagram.js`. Since 6.1.0.
+
+**The export is the whole `treedb_schema_<db>.c`.** `schema_to_c()` writes the
+graph of the schema as a comment — one box per topic, `*` required, `=`
+inherited, `(2)` pkey2, `(t)` tkey, the hook markers `{}` `[]` `()` and the
+fkey markers `(↖)` `[↖]` `{↖}`, and a line from each hook's row to the row of
+the fkey it fills — and then the literal, and that is all such a file holds:
+an edit made in the editor goes back into the source by replacing the file
+whole. The graph is `schema_to_diagram()`, derived and never drawn by hand;
+`json_to_c()` writes the same file from the literal's own JSON (the yunetas
+script `scripts/schema_diagram.mjs` uses it to keep the files in the repo
+equal to what an export would give). `with_diagram: false` gives the literal
+alone. Since 7.23.197.
+
+```c
+/*
+    Generated from the literal below by schema_to_diagram() (gobj-ui).
+    ...
+                    users
+            ┌───────────────────────────┐
+            │* id                       │
+            │  name (2)                 │
+            │           departments [↖] │ ──────┘
+            └───────────────────────────┘
+*/
+
+static char treedb_schema_sample[]= "\
+{                                                                   \n\
+    'id': 'treedb_sample',                                          \n\
+    ...
+```
 
 **A drag can be undone.** Reordering a column is a WRITE — `order` is a field —
 so the drop lands in the store the moment you let go. The toolbar grows an