Summary: Add accessibility-focused themes for visual impairments and optional bar/tray integration via low-coupling status output patterns suited to Waybar/Swaybar ecosystems. Related planning: dev/IMPROVEMENTS/FEATURE_PRIORITY.md (a11y ~v0.8.0).
1) Accessibility themes
Problem
Low vision and color-blind users need higher contrast, larger semantic cues, and reduced reliance on color alone.
Recommended implementation
- Theme pack: Additional
theme.conf presets or named themes: high contrast light/dark, protanopia/deuteranopia-friendly palettes (validate with contrast tools).
- Tweakables: optional global spacing/unicode icon substitutions where Ratatui allows.
- Config:
theme = high_contrast_dark etc.; document in example config/theme.conf per project rules when implemented.
- Focus indicators: ensure focus rings use brightness/symbols, not color-only.
Acceptance criteria
- Themes pass configurable minimum contrast ratio targets (document ratio in theme docs).
- Help overlay remains readable in all bundled a11y themes.
Testing
- Snapshot tests of rendered spans where feasible; manual checklist for common terminals.
2) System tray / panel status icons
Problem
Users want Pacsea presence on Wayland/X11 bars (Waybar, Swaybar, etc.) for quick launch or update status.
Recommended implementation options
Option A — External companion (lower coupling)
Small optional daemon or script emits status via file/socket that Waybar custom module reads; Pacsea writes “updates available” when invoked with --status-json or similar one-shot.
Option B — In-process tray (higher effort)
Rust crate for StatusNotifier / libappindicator; heavy platform/GUI dependency — likely poor fit for pure TUI.
Recommendation: Start with Option A: extend CLI with machine-readable status flags (pending updates count, last sync error) suitable for bars; provide example Waybar config snippet in repo contrib/ or wiki when allowed.
Acceptance criteria
- No tray feature required for core Pacsea; purely optional.
- Status command completes quickly; respects same privilege/tool detection as main app where needed.
Risks
- Wayland vs X11 tray protocols differ; document limitations.
Tracking: dev/ROADMAP/OTHER_accessibility_and_tray.md
Summary: Add accessibility-focused themes for visual impairments and optional bar/tray integration via low-coupling status output patterns suited to Waybar/Swaybar ecosystems. Related planning:
dev/IMPROVEMENTS/FEATURE_PRIORITY.md(a11y ~v0.8.0).1) Accessibility themes
Problem
Low vision and color-blind users need higher contrast, larger semantic cues, and reduced reliance on color alone.
Recommended implementation
theme.confpresets or named themes: high contrast light/dark, protanopia/deuteranopia-friendly palettes (validate with contrast tools).theme = high_contrast_darketc.; document in exampleconfig/theme.confper project rules when implemented.Acceptance criteria
Testing
2) System tray / panel status icons
Problem
Users want Pacsea presence on Wayland/X11 bars (Waybar, Swaybar, etc.) for quick launch or update status.
Recommended implementation options
Option A — External companion (lower coupling)
Small optional daemon or script emits status via file/socket that Waybar
custommodule reads; Pacsea writes “updates available” when invoked with--status-jsonor similar one-shot.Option B — In-process tray (higher effort)
Rust crate for StatusNotifier / libappindicator; heavy platform/GUI dependency — likely poor fit for pure TUI.
Recommendation: Start with Option A: extend CLI with machine-readable status flags (pending updates count, last sync error) suitable for bars; provide example Waybar config snippet in repo
contrib/or wiki when allowed.Acceptance criteria
Risks
Tracking:
dev/ROADMAP/OTHER_accessibility_and_tray.md