| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Neither scan property self-terminates. BlueZ discovery runs until
StartDiscovery is stopped, and the NetworkManager scanner repeats until
disabled; the docs for both say as much and give no timeout or interval
property. The scan button was the only writer of either property, and
closing the drawer destroys the page without touching them, so a scan
started and forgotten kept the radio busy for the rest of the session.
Continuous wifi scanning also costs throughput on the connected link.
Each page gets a Timer bound to the scan property rather than started by
the button. Binding it that way means a manual stop cancels the clock,
and reopening the page on a scan still running from an earlier visit
re-arms a fresh 60s instead of leaving it running forever.
Verified both files parse: the desktop shell hot-reloaded without
dropping its process. The timeout firing at 60s is not verified here,
since it needs a real scan on the radio.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01A7ThHHh5iTYbVfp3rNAkw2
|
|
|
|
|
|
|
|
|
|
Quickshell has no BlueZ agent and no generic D-Bus module, so a pairing
that needs a passkey confirmed cannot be done from QML. bluetoothctl
registers its own agent, so pairing is the one shell-out; adapter state,
scanning, connecting and forgetting all stay native.
The timeout is the ceiling: a device bluetoothctl cannot auto-confirm
fails visibly rather than hanging the page.
|
|
|
|
Native Quickshell.Bluetooth for adapter power, discoverable, scan,
connect, disconnect, trust and forget. Pairing is separate, because
quickshell ships no BlueZ agent.
The adapter is null for the first ~2s, so every access is navigated
safely rather than assuming a first paint.
|
