Explicit Writer and Hotkey modes
Why: Only the input behavior needed for the current task should be active.
Tradeoff: Every subsystem has to respond consistently when the application mode changes.
Back to engineering proof
Active
Creator and developerWindowsHelperSuite
Modular Windows writing, hotkey, speech, and device-assistance tools
The problem
Writing assistance, global hotkeys, speech input, and device controls often live in separate utilities. Switching between them adds friction and can make the tools interfere with one another.
The approach
A modular .NET solution with explicit Writer and Hotkey modes. A mode manager coordinates keyboard hooks, overlays, prediction, speech, and settings so only the intended subsystem is active.
Evidence in the implementation
These points are grounded in the project repository, its tests, and its technical documentation. They are not estimates of business impact.
Architecture evidence
The solution separates Core contracts, App orchestration and UI, Infrastructure, Hotkeys, Input, Overlay, Prediction, Settings, Speech, Writer, VoiceBridge, and test projects.
Testing
The test project includes focused coverage for typing-model behavior, prediction ranking, sentence context, title hints, and word-buffer policy.
Accessibility and control
The mode menu is available through a global keyboard gesture, mode changes can be shown or spoken, and the hook can consume the gesture so it does not leak into the focused application.
Known constraint
This is a Windows-native suite with low-level input and desktop integration. That enables system-wide behavior but increases platform-specific testing and installation work.
Working outcomes
Writer mode enables input hooks, overlays, suggestions, and writer hotkeys while disabling volume hotkeys
Evidence: Documented in the mode-system contributor guide.
Hotkey mode turns writer assistance off and enables system and volume shortcuts
Evidence: Documented in the mode-system contributor guide and enforced through mode guards.
Prediction is separated into providers, ranking, caching, context, and local language-model storage
Evidence: Represented by dedicated Writer services, providers, ranking, models, and storage modules.
Technical choices and tradeoffs
Provider-and-ranker prediction pipeline
Why: Prefix, phrase-memory, next-word, correction, recency, and local-model candidates can evolve independently.
Tradeoff: Candidate ranking and context become their own systems that require focused tests.
Persist mode and typing settings as JSON
Why: Desktop behavior can survive restarts without requiring a service or database.
Tradeoff: Settings schema compatibility has to be maintained as modes and options evolve.
Technical foundation
- C#
- .NET
- WPF
- Low-level keyboard hooks
- JSON settings
- xUnit