Choose the VoidKontrol service, UI, and desktop integration architecture #6
Notifications
Due Date
No due date set.
Blocks
Depends on
#8 Validate the Carbon keyboard-customization and recovery workflows
xavierk/voidkontrol
#9 Set the evidence-based VoidKontrol v1 release and handoff criteria
xavierk/voidkontrol
#2 Establish the Void Linux runtime, permissions, and packaging requirements
xavierk/voidkontrol
#3 Establish the native niri and Noctalia integration contracts
xavierk/voidkontrol
#4 Establish a faithful IBM Carbon desktop UI strategy for Void Linux
xavierk/voidkontrol
Reference: xavierk/voidkontrol#6
Reference in New Issue
Block a user
Question
Using the three platform/design investigations, which small architecture should own device transactions, authorization, persistence, unprivileged UI/CLI access, and niri/Noctalia integration? Set the v1 platform/ABI baseline; choose the UI/runtime, daemon language and IPC contract; decide the Noctalia surface and Carbon/theme boundary. Preserve a single hidraw owner with narrowly scoped access and no dependency on systemd. Resolve through a live user exchange, considering dependency footprint, delivery effort, maintainability, and accessibility. Recommendations are not decisions until accepted.
Parent map: Find the way to VoidKontrol v1: complete verified Swarm75 control on Void Linux