Skip to content

split macOS daemon from on-demand Qt UI#243

Draft
Vonkid wants to merge 1 commit into
TomBadash:masterfrom
Vonkid:agent/lightweight-macos-daemon
Draft

split macOS daemon from on-demand Qt UI#243
Vonkid wants to merge 1 commit into
TomBadash:masterfrom
Vonkid:agent/lightweight-macos-daemon

Conversation

@Vonkid

@Vonkid Vonkid commented Jul 16, 2026

Copy link
Copy Markdown

What changed

  • replaces the resident macOS Qt tray process with a lightweight AppKit status-item daemon
  • runs Settings, the original Actions Ring, and screenshot UI in a separate on-demand MouserUI.app helper
  • adds authenticated daemon/UI IPC and local single-instance control
  • packages the daemon and Qt helper as separate PyInstaller analyses so the daemon never runs the PySide6 runtime hook
  • keeps the original Actions Ring visuals and behavior unchanged

Why

The existing single executable imports QtCore at process startup through PyInstaller's PySide6 runtime hook, even when the settings window is closed. That leaves the complete GUI runtime resident for a background mouse remapper.

This is separate from, and complementary to, the native leaks tracked in #233 and #238. Those fixes keep memory from growing over time; this change reduces the stable baseline by keeping Qt out of the resident process entirely.

On the tested Apple Silicon system, Activity Monitor settled from roughly 280 MB to roughly 48 MB after the split. Settings and the original Actions Ring start only while used and exit afterward.

Validation

  • 13 focused bridge/process-policy tests pass (2 sandbox-dependent Unix-socket tests skipped)
  • daemon import-surface check reports no PySide6 or ui.backend modules
  • current master builds successfully as a dual-app PyInstaller bundle
  • the staged app and nested helper pass codesign --verify --deep --strict
  • the release ZIP passes signature verification after extraction
  • MX Master 4 HID connection, remapping, Action Ring, Settings, and Accessibility behavior were tested on macOS

This is intentionally a draft because the process split is substantial and would benefit from maintainer feedback on IPC and packaging boundaries.

TomBadash pushed a commit that referenced this pull request Jul 22, 2026
Arrange every issue and PR referring to the long-running macOS memory
growth (#125, #150/#151, #233/#242, #238/#240, #243) into one status
document, synthesize the post-fix test evidence into the three remaining
root causes (un-pooled HID read-loop pump, un-pooled auxiliary threads,
GPProcessMonitor XPC accumulation from 0.3s app polling), and define a
phased plan: land validated PRs #240/#242, hotfix the read-loop pool for
v3.7.1, move app detection to NSWorkspace notifications for v3.8, add
footprint logging and regression gates, and review the #243 daemon split.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uB8aXzbsRT1jAAwAP9roA
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant