jochen
de7aca4fa6
The operator asked for one place that lists every module's preferences and each machine's value, and for a list of the values the catalogues hard-code that should become preferences.
1.7 KiB
status, initiated, touches, became
| status | initiated | touches | became | ||||
|---|---|---|---|---|---|---|---|
| active | 2026-10-08 |
|
037 — The catalogue's hard-coded preferences
What is investigated
ADR 0262 lets a manifest give a preference a default, which the mesh-wide settings and a node's settings override. Before it, a value a person might want to tune per machine could only be written into a module's file as a literal. This effort lists those literals in both catalogues: the value, where it is, the key and default it would take as a preference, and why a person would change it.
Why
The first case was the notifier's font size, which is less than half as tall on a laptop panel of about 240 DPI as on a desktop monitor of about 110 DPI, while X is told 96 on both. The same is true of every size, font and gap on the desktop, and of retention counts, timeouts and thresholds in the services. A list says which modules to convert, in what order, and which values are shared between modules and should keep one default.
What it touches
The manifests of both catalogues, and through ADR 0262 the controller's settings verb, which lists
every declared preference. Nothing is changed here: each conversion is a change to its module, made on
the operator's yes.
Documents
- 01 — the survey: every candidate, by module, strongest first, with the modules that already take settings and those that have nothing to convert.