Roadmap #45
Roadmap #45
Conversation
Linking filter to source and sink not yet working
….g. easyeffects can be used, or built-in filter with hard-coded parameters
| - ModeController class with state machine (AUTO | MANUAL | MIXED) | ||
| - Hardware access locking (threading.Lock or asyncio.Lock) | ||
| - Transition handlers (pause auto mode, resume auto mode) | ||
| - Watchdog timer for manual mode timeout |
There was a problem hiding this comment.
Suggest an option to not set the timer, to enable a manual config to run indefinitely if desired.
| - GET /mode/status - Current mode and locked quadrants | ||
| - POST /manual/draw/left - Send left panel pattern (9×34 array) | ||
| - POST /manual/draw/right - Send right panel pattern (9×34 array) | ||
| - POST /manual/quadrant - Control specific quadrant |
There was a problem hiding this comment.
Where is the current manual config persisted? Should we have a separate config file for manual mode? In memory?
|
|
||
| 1. **Project Setup** | ||
|
|
||
| - Vite + React + TypeScript |
There was a problem hiding this comment.
Vite is probably fine, but it's worth asking the question whether we anticipate sufficient complexity to drive us toward Next.js
|
|
||
| 1. **Project Setup** | ||
|
|
||
| - Vite + React + TypeScript |
There was a problem hiding this comment.
Any preference for rendering library? I switched from Bootstrap to Tailwind CSS a couple years ago and find it very good.
| - Vite + React + TypeScript | ||
| - API client library (axios or fetch) | ||
| - WebSocket client | ||
| - State management (Zustand or React Context) |
There was a problem hiding this comment.
I'm not familiar with Zustand, but I see it's lightweight and Flux-based, so that sounds good. Will defer to you on preference vis-à-vis React Context. I think we both agree there's not sufficient complexity to justify Redux.
|
|
||
| 1. **System Alerts Configuration** (from notification API design) | ||
|
|
||
| - Define alert triggers |
There was a problem hiding this comment.
Since alerts are transient, should they preempt the current display? Should we configure one or more quadrants to be the place where alerts go when they occur? Should we have a configurable time persistence?
|
|
||
| - POST /mode/manual - Request manual control | ||
| - POST /mode/auto - Release manual control | ||
| - POST /manual/draw - Receive pattern from dotmatrixtool |
There was a problem hiding this comment.
| - POST /manual/draw - Receive pattern from dotmatrixtool | |
| - POST /manual/draw/left - Send left panel pattern (9×34 array) dotmatrixtool | |
| - POST /manual/draw/right - Send right panel pattern (9×34 array) dotmatrixtool |
For consistency with Option A description
| - POST /mode/manual - Request manual control | ||
| - POST /mode/auto - Release manual control | ||
| - POST /manual/draw - Receive pattern from dotmatrixtool | ||
| - POST /config/quadrant - Configure quadrant app |
There was a problem hiding this comment.
| - POST /config/quadrant - Configure quadrant app | |
| - POST /manual/quadrant - Configure specific quadrant |
For consistency with Option A description
| - GET /config - Current configuration | ||
| - GET /metrics - System metrics | ||
| - WebSocket /ws - Live state updates | ||
|
|
There was a problem hiding this comment.
Why are other endpoints from Option A not included here? Less GUI implementation, I assume?
| - Validates the architecture quickly | ||
| - Solves the mode management problem first | ||
| - Provides working system faster | ||
| - Allows React migration when UI needs justify effort |
There was a problem hiding this comment.
SUggest consideration of Option C: Implement the client with React.JS but leave alerts capability for the next iteration.
Rationale: Implementing mode and app control in vanilla JS is non-trivial. Would the ease we gain from doing it in React to begin with be worth the effort to port existing dotmatrix code to React? The GUI elements would easily port (we could even just wrap them in an iframe for the first iteration) and jquery -> React translation should be straightforward. Alert capability is a big chunk, involving significant UI and backend work, and may be a better candidate for deferral than React implementation.
Just bringing this up for consideration. I'm not necessarily preferring it. Would like to hear your take on it.
Creating this PR as a means of discussing the roadmap file