firecat53 / networkmanager-dmenu

Control NetworkManager via dmenu
MIT License
783 stars 74 forks source link

allow controlling bluetooth with a bluez #127

Closed craftyguy closed 7 months ago

craftyguy commented 10 months ago

bluez can generally be used by non-root users without having to add udev rules / access /dev/rfkill directly. there's a dbus API but I don't see any obvious methods for managing BT adapter power... but using bluetoothctl directly (e.g. bluetoothctl power on/off for the default adapter) would be a simple option too I think.

firecat53 commented 10 months ago

I added bluetoothctl as an option for controlling bluetooth to the develop branch. Let me know if it works for you. Try to break it if you can :) Thanks!

craftyguy commented 10 months ago

Excellent!!

There were a couple of small bugs I've found so far, that I've resolved / worked around in this patch (feel free to improve further or whatever):

diff --git a/networkmanager_dmenu b/networkmanager_dmenu
index f668422..0db30a9 100755
--- a/networkmanager_dmenu
+++ b/networkmanager_dmenu
@@ -658,6 +658,9 @@ def toggle_bluetooth(enable):
                                  capture_output=True)
         except subprocess.TimeoutExpired:
             pass
+        # give the controller a little time to change power states before
+        # querying status
+        sleep(1)
         try:
             res = subprocess.run(['bluetoothctl', 'show'],
                                  timeout=2,
@@ -665,9 +668,12 @@ def toggle_bluetooth(enable):
                                  text=True)
             if "Powered: yes" in res.stdout:
                 notify("Bluetooth enabled")
-                return
+            else:
+                notify("Bluetooth disabled")
+            return
         except subprocess.TimeoutExpired:
             pass
     # Now try using rfkill
     type_bluetooth = 2
     op_change_all = 3

Without the small delay between changing power and getting status, this app was reporting the wrong status most of the time. Hardcoding a delay like this isn't great...

This also fixes a bug where rfkill was still run when bluetoothctl was able to successfully power off the device.