1# llimphi-module-allichay
2
3The single renderer of declarative configuration.
4
5It takes an `allichay::Schema` and paints it with the **unified sidebar**
6(`llimphi-widget-rag-sidebar`): one tooth per top-level section and, in the
7active tooth's panel, scalar controls for the fields (toggle, slider, dropdown,
8colour, text). The rail, the panel, the uniform header (the section's title), the
9search box and the layout control are painted by ONE widget — allichay does not
10re-derive chrome. Changes come out as an `AllichayMsg` the host maps to its own
11`Msg`.
12
13The schema-driven body (`section_view`/`schema_panel`) is exposed separately for
14hosts that already have their own rail (for instance `wawa-panel`): those reuse
15the field rendering without the internal sidebar.
16
17It is a module in the `command-palette` style: it contributes `state + Msg +
18apply_key + view`. The host:
19
201. keeps an `AllichayState` in its model;
212. calls `allichay_view` in its `view`, mapping `AllichayMsg` → its `Msg`;
223. routes keys to `AllichayState::apply_key` while a text field is focused;
234. on an `AllichayMsg::Change`, applies the `(FieldPath, FieldValue)` to its
24 config (through `allichay::Configurable::apply`) and persists it with its own
25 `save()` — allichay never touches the disk.
26
27Subsections: in v1 they are painted as headed groups inside the active section's
28panel (a single level of teeth). The central panel combines apps in a scheme
29where each app is a section-tooth and its real sections drop to subsections — so
30one rail navigates "apps → sections".
31
32---
33
34Part of **llimphi** — see [llimphi](../../README.md).
README.md
llimphi-module-allichay
The single renderer of declarative configuration.
It takes an allichay::Schema and paints it with the unified sidebar
(llimphi-widget-rag-sidebar): one tooth per top-level section and, in the
active tooth's panel, scalar controls for the fields (toggle, slider, dropdown,
colour, text). The rail, the panel, the uniform header (the section's title), the
search box and the layout control are painted by ONE widget — allichay does not
re-derive chrome. Changes come out as an AllichayMsg the host maps to its own
Msg.
The schema-driven body (section_view/schema_panel) is exposed separately for
hosts that already have their own rail (for instance wawa-panel): those reuse
the field rendering without the internal sidebar.
It is a module in the command-palette style: it contributes state + Msg + apply_key + view. The host:
- keeps an
AllichayState in its model;
- calls
allichay_view in its view, mapping AllichayMsg → its Msg;
- routes keys to
AllichayState::apply_key while a text field is focused;
- on an
AllichayMsg::Change, applies the (FieldPath, FieldValue) to its
config (through allichay::Configurable::apply) and persists it with its own
save() — allichay never touches the disk.
Subsections: in v1 they are painted as headed groups inside the active section's
panel (a single level of teeth). The central panel combines apps in a scheme
where each app is a section-tooth and its real sections drop to subsections — so
one rail navigates "apps → sections".
Part of llimphi — see llimphi.