gioser

tawasuyu/llimphi

Sovereign retained-mode GPU UI framework in Rust (wgpu+vello+taffy+parley), Elm loop, 40+ widgets.

Rust 614Markdown 274TOML 149RON 310606 Sutichaykuna

⎇ c5a232cf24788ab75a850ffe81eca5a7af50e2f8 llimphi-workspace/README.md Markdown · 35 siq'ikuna · 1.3 KB Ñawpa willay ch'uya

chore: refresco desde el monorepo — 27 crates nuevos (anim, lottie, svg, mesh, image, layer, test, wire-view, widgets rag-sidebar/router/lazy-list/rive-button) y sync de los 95 existentes 93253cc22 · Sergio ·

1# llimphi-workspace
2
3Generic tmux-style chassis.
4
5Step 2 of the "mount any tawasuyu component in an interchangeable layout with
6resizable splits" vision. Where `llimphi_widget_panes` contributes the **tree**
7(structure + render + drag), this crate contributes the **state machine** (which
8panel is focused, how it splits and closes, the id counter) plus the **standard
9chrome** (a split/close toolbar).
10
11## How an app uses it
12
13The app keeps a `Workspace` in its `Model` and a `HashMap<PaneId, …>` with each
14panel's state. Its `Msg` wraps two things:
15
16```ignore
17enum Msg {
18    Ws(WsMsg),                 // chassis messages (focus/split/…)
19    Panel(PaneId, PanelMsg),   // messages of a concrete panel
20}
21```
22
23In `update`, the `Ws` ones are applied with `Workspace::apply`, which returns a
24`WsEffect` telling whether to **create** the state of a new panel or **delete**
25that of a closed one. In `view`, `workspace_view` assembles the chrome plus the
26tree; the app only provides each leaf's content (already lifted to its own `Msg`
27— the chassis never touches the `PanelMsg`s).
28
29The lift happens while building the view (like `shuma-module`), which sidesteps
30the lack of `View::map` without `Box<dyn Any>`: the chassis is generic over the
31host's `Msg` and never downcasts.
32
33---
34
35Part of **llimphi** — see [llimphi](../README.md).

README.md

llimphi-workspace

Generic tmux-style chassis.

Step 2 of the "mount any tawasuyu component in an interchangeable layout with resizable splits" vision. Where llimphi_widget_panes contributes the tree (structure + render + drag), this crate contributes the state machine (which panel is focused, how it splits and closes, the id counter) plus the standard chrome (a split/close toolbar).

How an app uses it

The app keeps a Workspace in its Model and a HashMap<PaneId, …> with each panel's state. Its Msg wraps two things:

enum Msg {
    Ws(WsMsg),                 // chassis messages (focus/split/…)
    Panel(PaneId, PanelMsg),   // messages of a concrete panel
}

In update, the Ws ones are applied with Workspace::apply, which returns a WsEffect telling whether to create the state of a new panel or delete that of a closed one. In view, workspace_view assembles the chrome plus the tree; the app only provides each leaf's content (already lifted to its own Msg — the chassis never touches the PanelMsgs).

The lift happens while building the view (like shuma-module), which sidesteps the lack of View::map without Box<dyn Any>: the chassis is generic over the host's Msg and never downcasts.


Part of llimphi — see llimphi.