renew: stage 2, 3 #26

New issue

Open

opened 2026-04-30 11:36:42 +02:00 by kir68k · 1 comment

kir68k commented

2026-04-30 11:36:42 +02:00

Owner

Focus: Scaffolding the UI

Notes

After the initial porting of the login flow from #19 (stage 1),
i should start writing the tui. To start with something, app struct should have a state field, which is an enum tracking the currently displayed tui page/view/screen/...

I'll have to think about the ui design itself; whether it should be based on a main "view" and a tab bar (?) or something else. I kinda liked the gui layout, so I might try replicating it, or parts of it.

In any case, src/view.rs should be split into submodules, possibly per state (e.g. login.rs / loading.rs and such?).

The tui will also require implementing Tick, Input(KeyEvent), and Shutdown messages in handle.rs.
The tick simply draws the current view, according to the state.

For now rendering can occur per-tick, rather than on state changes, for simplicity.

I think the running field on Lattice can be removed, I added it way earlier when I thought of just using a main + event loop, like while self.running { /* wait for any event like input, rendering tick, or app feature/functionality */ }.

Progress

Stage 2
Stage 3

**Focus**: Scaffolding the UI ## Notes After the *initial* porting of the login flow from #19 (stage 1), i should start writing the tui. To start with *something*, app struct should have a `state` field, which is an enum tracking the currently displayed tui page/view/screen/... I'll have to think about the ui design itself; whether it should be based on a main "view" and a tab bar (?) or something else. I kinda liked the gui layout, so I might try replicating it, or parts of it. In any case, `src/view.rs` should be split into submodules, possibly per state (e.g. `login.rs` / `loading.rs` and such?). The tui will also require implementing `Tick`, `Input(KeyEvent)`, and `Shutdown` messages in `handle.rs`. The tick simply draws the current view, according to the `state`. For now rendering can occur per-tick, rather than on state changes, for simplicity. I think the `running` field on `Lattice` can be removed, I added it way earlier when I thought of just using a main + event loop, like `while self.running { /* wait for any event like input, rendering tick, or app feature/functionality */ }`. **Progress** - [ ] Stage 2 - [ ] Stage 3

kir68k added this to the a new start project

2026-04-30 11:36:42 +02:00

kir68k added a new dependency

2026-04-30 11:36:51 +02:00

#25 renew: stage 1

kir68k commented

2026-04-30 11:45:27 +02:00

Author

Owner

renew: stage 3 (smol enough to just be a comment)

Focus: Login UI

Notes

After having some initial structure for tui, i can add a login ui view. The most basic would be:

Two inputs; full username/id, and password (masked)
Focus switch with tab/shift-tab
Enter key input will lattice.tell(LoginRequested { .. })
Display error in pwetty way if LoginFailed
Loading screen for Loading.

However it should preferably be a picker; three cards with title for login method + description string. This is because pw-based login isn't the only method I'll want to support. The two-input screen can just be selected instead.

renew: stage 3 (smol enough to just be a comment) ---- **Focus**: Login UI ## Notes After having some initial structure for tui, i can add a login ui view. The most basic would be: - Two inputs; full username/id, and password (masked) - Focus switch with tab/shift-tab - `Enter` key input will `lattice.tell(LoginRequested { .. })` - Display error in pwetty way if `LoginFailed` - Loading screen for `Loading`. However it should preferably be a picker; three cards with title for login *method* + description string. This is because pw-based login isn't the only method I'll want to support. The two-input screen can just be selected instead.

kir68k added a new dependency

2026-04-30 12:02:46 +02:00

#27 renew: stage 4