Roadmap

[MidnightJava]

Creating this PR as a means of discussing the roadmap file

[MidnightJava]

Suggest an option to not set the timer, to enable a manual config to run indefinitely if desired.

[timoteuszelle]

Agreed. I see manual mode having two variants:

Temporary Manual Mode (default):

• Timeout-based (e.g., 5 min default, configurable)
• Use case: Quick testing of icons/animations, showcase demos, drawing experiments
• Returns to user's default configuration after timeout

Persistent Manual Mode:

• No timeout - stays in manual until explicitly switched
• Use case: When you want to override the default behavior entirely
• Requires explicit switch back to configured default

The mode controller should support both via a toggle or API parameter.

Note on terminology: We should clarify "auto mode" vs "default mode":

• Default Mode - the user's configured baseline (from config.yaml or custom settings, not necessarily the application-shipped default)
• Manual Override - temporary deviation from default
• Persistent Override - permanent change until explicitly reverted

This distinction matters because a user's "default" might itself be a customized configuration, not the original application defaults.

[MidnightJava]

Where is the current manual config persisted? Should we have a separate config file for manual mode? In memory?

[timoteuszelle]

This depends on the use case and will tie into the service/plugin implementation:

Mode types we should support:

• DEFAULT - user's baseline configuration (from config.yaml or saved custom settings)
• MANUAL_TEMP - temporary override (in-memory, optional timeout)
• MANUAL_PERSIST - persistent override until explicitly changed
• OFF - specific quadrant(s) disabled
• Per-quadrant app selection (from installed plugins)

Persistence strategy:

• In-memory for temporary manual/testing
• Saved configurations (custom defaults, installed plugins) persist to disk
• Users can save "preset configurations" that combine settings

The specifics will depend on how we implement the service layer and plugin management.

[MidnightJava]

Vite is probably fine, but it's worth asking the question whether we anticipate sufficient complexity to drive us toward Next.js

[timoteuszelle]

Vite should be sufficient for the MVP.

Next.js would only make sense if we go the full plugin installation/configuration/management route, which brings significant complexity. For now, let's start with Vite and keep it simple. We can reassess if requirements change.

[MidnightJava]

Any preference for rendering library? I switched from Bootstrap to Tailwind CSS a couple years ago and find it very good.

[timoteuszelle]

Agreed on Tailwind. Let's keep it lightweight and simple - the matrix itself is limited in presentation capabilities, so we don't need heavy UI frameworks. Tailwind + minimal component library (if needed) should be sufficient.

[MidnightJava]

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.

[timoteuszelle]

I defer to Mark's experience here. Zustand or React Context both sound reasonable for this scope. Mark, what's your preference?

[MidnightJava]

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?

[timoteuszelle]

I like the idea of templates/presets for alert behavior:

Alert Templates:

• Preemptive (interrupt current display temporarily)
• Dedicated quadrant (always show in specific location)
• System tray only
• Custom (user-defined behavior)

Customization per template:

• Which quadrant(s) to use
• Timeout/persistence duration
• Priority levels
• Whether alerts can interrupt or only queue

This gives flexibility while keeping it manageable. All alert features are open for discussion - we should prioritize what makes sense for MVP.

[MidnightJava]

Suggested change

	- 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

[timoteuszelle]

Agreed - consistency is important for maintainability and potential future migration.

[MidnightJava]

Suggested change

	- POST /config/quadrant - Configure quadrant app
	- POST /manual/quadrant - Configure specific quadrant

For consistency with Option A description

[timoteuszelle]

Agreed - consistency is important for maintainability and potential future migration.

[MidnightJava]

Why are other endpoints from Option A not included here? Less GUI implementation, I assume?

[timoteuszelle]

Good point - we should probably include all endpoints regardless of which option we choose, for consistency and to avoid limiting future functionality.

[MidnightJava]

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.

[timoteuszelle]

I agree with this approach. Let's deliver the MVP with the core of what we have now, and build from there.

[timoteuszelle]

Thanks for the detailed review! Here are my responses to your comments:

1. Manual Mode Timer (Line 54)

Agreed. I see manual mode having two variants:

Temporary Manual Mode (default):

• Timeout-based (e.g., 5 min default, configurable)
• Use case: Quick testing of icons/animations, showcase demos, drawing experiments
• Returns to user's default configuration after timeout

Persistent Manual Mode:

• No timeout - stays in manual until explicitly switched
• Use case: When you want to override the default behavior entirely
• Requires explicit switch back to configured default

The mode controller should support both via a toggle or API parameter.

Note on terminology: We should clarify "auto mode" vs "default mode":

• Default Mode - the user's configured baseline (from config.yaml or custom settings, not necessarily the application-shipped default)
• Manual Override - temporary deviation from default
• Persistent Override - permanent change until explicitly reverted

This distinction matters because a user's "default" might itself be a customized configuration, not the original application defaults.

2. Manual Config Persistence (Line 64)

This depends on the use case and will tie into the service/plugin implementation:

Mode types we should support:

• DEFAULT - user's baseline configuration (from config.yaml or saved custom settings)
• MANUAL_TEMP - temporary override (in-memory, optional timeout)
• MANUAL_PERSIST - persistent override until explicitly changed
• OFF - specific quadrant(s) disabled
• Per-quadrant app selection (from installed plugins)

Persistence strategy:

• In-memory for temporary manual/testing
• Saved configurations (custom defaults, installed plugins) persist to disk
• Users can save "preset configurations" that combine settings

The specifics will depend on how we implement the service layer and plugin management.

[timoteuszelle]

3. Framework Choice - Vite vs Next.js (Line 88)

Vite should be sufficient for the MVP.

Next.js would only make sense if we go the full plugin installation/configuration/management route, which brings significant complexity. For now, let's start with Vite and keep it simple. We can reassess if requirements change.

4. CSS Framework - Tailwind (Line 88)

Agreed on Tailwind. Let's keep it lightweight and simple - the matrix itself is limited in presentation capabilities, so we don't need heavy UI frameworks. Tailwind + minimal component library (if needed) should be sufficient.

5. State Management - Zustand (Line 91)

I defer to Mark's experience here. Zustand or React Context both sound reasonable for this scope. Mark, what's your preference?

6. App Configuration per App (Line 106)

Yes, essential feature. This ties into the broader configuration/plugin system:

• Apps/plugins should have configurable arguments
• API should expose available settings per app
• Frontend provides interface to configure these args
• Configurations can be saved as presets/templates
• Support both temporary testing and persistent custom configs

The exact implementation depends on how we structure the plugin/service architecture.

Important: Configuration files should remain human-readable (YAML, TOML, etc.) so they can be edited via CLI editors for users without GUI access. The web interface is just another way to edit the same underlying config files.

[timoteuszelle]

7. Manual Control Interface Design (Line 112)

The way I see it, there are two main aspects:

1. Configuration Management:

• If you have a configuration different from application defaults (customizations, added plugins), you'd want it to persist after reboots/restarts
• Two approaches:
  • Simple: Basic preset interface with combinable settings templates
  • Advanced: Full plugin management system (more complexity)

2. Quick Access:

• Ability to quickly showcase/test icons, animations, or drawings
• Load preset configurations or templates
• Reusable templates for common patterns

The app config widget from default mode should be reusable, with added preset/template support.

8. Color LED Availability (Line 122)

Not aware of commercial availability yet - just the community POC.

For implementation: let's future-proof for RGB but don't over-engineer it. If we can support limited grayscale now with minimal extra work to accommodate RGB later, great. If it becomes complex, we can drop RGB support easily. It's mainly acknowledging that at least one color implementation exists in the wild.

9. Alert Behavior (Line 139)

I like the idea of templates/presets for alert behavior:

Alert Templates:

• Preemptive (interrupt current display temporarily)
• Dedicated quadrant (always show in specific location)
• System tray only
• Custom (user-defined behavior)

Customization per template:

• Which quadrant(s) to use
• Timeout/persistence duration
• Priority levels
• Whether alerts can interrupt or only queue

This gives flexibility while keeping it manageable. All alert features are open for discussion - we should prioritize what makes sense for MVP.

[timoteuszelle]

10 & 11. Option B API Consistency (Lines 199-200)

Agreed - consistency is important for maintainability and potential future migration.

12. Option B Endpoint Differences (Line 204)

Good point - we should probably include all endpoints regardless of which option we choose, for consistency and to avoid limiting future functionality.

13. Option C Proposal - React First, Defer Alerts (Line 307)

I agree with this approach. Let's deliver the MVP with the core of what we have now, and build from there.

[MidnightJava]

Thanks for your response, Tim. I agree with all your comments, so I think we're on the same page. Would you like to update the roadmap doc to reflect the additional info you provided in your comments, as well as incorporate the changes we discussed?

What are your thoughts about next steps? Seems like we have three categories of development tasks: 1) fastapi implementation 2) updates to backend python code 3) Front-end development. The last one is probably the highest effort and can also be deferred until we at least have the service endpoints defined precisely. Seems like developing the API first (endpoint specifications, not implementation) is a good idea, but that's probably best done by a single author, for consistency of approach and conventions. If you want to take a cut at that, we can then collaborate from there as a good starting point. If you'd rather divvy that up, however, that's fine. I have maybe a couple more days of work on the equalizer widget, and then I'll be ready to transition to this effort.

Also, as to my preference for Zustand or Context: I only have experience with Redux and Context, so I don't really have a preference wrt Zustand. I assume you're familiar with Zustand, so if you think it's a good choice, I'm happy to go with it. Always ready to learn a new library, and it looks like Zustand is a pretty easy lift. But if you think Context is a better choice, that's fine also.