1# llimphi-workspace
2
3*Read this in English: [README.md](README.md).*
4
5Chasis genérico estilo tmux.
6
7Paso 2 de la visión "montar cualquier componente de tawasuyu en un layout
8intercambiable con splits resizables". Donde `llimphi_widget_panes`
9aporta el **árbol** (estructura + render + drag), este crate aporta la
10**máquina de estados** (qué panel está enfocado, cómo se parte/cierra,
11el contador de ids) + el **chrome estándar** (toolbar split/cerrar).
12
13## Cómo lo usa una app
14
15La app guarda un `Workspace` en su `Model` y un `HashMap<PaneId, …>`
16con el estado de cada panel. Su `Msg` envuelve dos cosas:
17```ignore
18enum Msg {
19 Ws(WsMsg), // mensajes del chasis (focus/split/…)
20 Panel(PaneId, PanelMsg), // mensajes de un panel concreto
21}
22```
23En `update`, los `Ws` se aplican con `Workspace::apply`, que devuelve
24un `WsEffect` indicando si hay que **crear** el estado de un panel
25nuevo o **borrar** el de uno cerrado. En `view`, `workspace_view` arma
26el chrome + el árbol; la app sólo provee el contenido de cada hoja (ya
27lifteado a su propio `Msg` — el chasis no toca los `PanelMsg`).
28
29El lift se hace al construir la vista (igual que `shuma-module`), así
30sorteamos la falta de `View::map` sin `Box<dyn Any>`: el chasis es
31genérico sobre el `Msg` del host y nunca downcastea.
32
33---
34
35Parte de **llimphi** — ver [llimphi](../LEEME.md).
LEEME.md
llimphi-workspace
Read this in English: README.md.
Chasis genérico estilo tmux.
Paso 2 de la visión "montar cualquier componente de tawasuyu en un layout
intercambiable con splits resizables". Donde llimphi_widget_panes
aporta el árbol (estructura + render + drag), este crate aporta la
máquina de estados (qué panel está enfocado, cómo se parte/cierra,
el contador de ids) + el chrome estándar (toolbar split/cerrar).
Cómo lo usa una app
La app guarda un Workspace en su Model y un HashMap<PaneId, …>
con el estado de cada panel. Su Msg envuelve dos cosas:
enum Msg {
Ws(WsMsg), // mensajes del chasis (focus/split/…)
Panel(PaneId, PanelMsg), // mensajes de un panel concreto
}
En update, los Ws se aplican con Workspace::apply, que devuelve
un WsEffect indicando si hay que crear el estado de un panel
nuevo o borrar el de uno cerrado. En view, workspace_view arma
el chrome + el árbol; la app sólo provee el contenido de cada hoja (ya
lifteado a su propio Msg — el chasis no toca los PanelMsg).
El lift se hace al construir la vista (igual que shuma-module), así
sorteamos la falta de View::map sin Box<dyn Any>: el chasis es
genérico sobre el Msg del host y nunca downcastea.
Parte de llimphi — ver llimphi.