* feat: add stem press track control and headless mode support
- Parse STEM_PRESS packets and emit AACPEvent::StemPress with press type and bud side
- Enable double/triple tap detection on init via StemConfig control command (0x06)
- Double press → next track, triple press → previous track via MPRIS D-Bus
- Add next_track() and previous_track() to MediaController
- Add --no-tray flag for headless operation without a GUI
- Replace unwrap() on ui_tx.send() calls with graceful warn! logging
(vibecoded)
* Update main.rs
* feat: make stem press track control optional with GUI toggle
Add a --no-stem-control CLI flag and a toggle in the Settings tab for
environments that handle AirPods AVRCP commands natively (e.g. via
BlueZ/PipeWire). The feature remains enabled by default.
- Load stem_control from app settings JSON on startup; --no-stem-control
overrides it to false regardless of the saved value
- Share an Arc<AtomicBool> between the async backend and the GUI thread;
AirPodsDevice holds the Arc directly so the event loop reads the live
value on every stem press — toggle takes effect immediately without
reconnecting
- Persist stem_control to settings JSON alongside theme and tray_text_mode
- Add a "Controls" section to the Settings tab with a toggler labelled
"Stem press track control", with a subtitle explaining the AVRCP
conflict scenario
- Fix StemConfig bitmask comment to clarify it uses a separate numbering
scheme from the StemPressType event enum values (0x05–0x08)
tbh, I did not want to get results right away; batching would have been fine. But, BlueR seems to give the first scan result only after 10s if I set sampling period.
