Closed paulmiddelkoop closed 1 year ago
Thank you for opening this issue!
🔔 @briankosw @VladCuciureanu you might want to have a look.
Notice: If anyone with more Obj-C experience sees this and finds any discrepancies, please do tell. \<rant> I like Apple. I love my M1 Max beast. With that said... Their public/documented bluetooth API sucks. \<\/rant>
So, I looked into it 😮💨
What I think happens here is that there's a bug on Apple's side which gets accidentally fixed when subscribing to the device's disconnect event. blueutil just treats the device as an 'IOBluetoothDevice', it subscribes to the event and waits for a certain timeout period after which it throws an error if no response arrived in the specified period of time. Nothing fancy (as far as I know). Even the blueutil's author was surprised this was a fix.
That said, there's nothing I can do right now. This is due to the fact that Raycast's AppleScript can't understand/access IOBluetoothDevices without the app itself (Raycast) declaring the need for bluetooth perms inside the App Sandbox. I have an implementation draft ready for testing but for now the fate of this lies in Raycast Team's hands.
tldr: Needs mods on Raycast's side. Messaged the dev team - now we wait.
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs in the next 7 days to keep our backlog clean 😊
I'm closing this due to inactivity; feel free to comment in the thread when you're ready to continue working on it 🙂 You can also catch us in Slack if you want to discuss.
Notice: If anyone with more Obj-C experience sees this and finds any discrepancies, please do tell.
I like Apple. I love my M1 Max beast. With that said... Their public/documented bluetooth API sucks. So, I looked into it 😮💨
What I think happens here is that there's a bug on Apple's side which gets accidentally fixed when subscribing to the device's disconnect event. blueutil just treats the device as an 'IOBluetoothDevice', it subscribes to the event and waits for a certain timeout period after which it throws an error if no response arrived in the specified period of time. Nothing fancy (as far as I know). Even the blueutil's author was surprised this was a fix.
That said, there's nothing I can do right now. This is due to the fact that Raycast's AppleScript can't understand/access IOBluetoothDevices without the app itself (Raycast) declaring the need for bluetooth perms inside the App Sandbox. I have an implementation draft ready for testing but for now the fate of this lies in Raycast Team's hands.
tldr: Needs mods on Raycast's side. Messaged the dev team - now we wait.
There is a workaround that worked for me:
Allow applications to access Bluetooth
+
button and select Raycast
That's an amazing find! I'll redirect people to your post until a better solution comes up! Thanks Juan for sharing it!
So, good news (kinda).
I implemented a compat-layer for 'blueutil' which improves this situation.
Connecting/disconnecting should be faster and less flaky. Testing was limited so I can't guarantee that it's perfect but, to me, it looks like an improvement :>
Extension
https://www.raycast.com/briankosw/toothpick
Description
Disconnecting does not work most of the times. The extension says "Device disconnected successfully.", but the device is still connected.
This is a common problem across other Bluetooth utilities also. See blueutil and BluetoothConnector issues.
The problem is that
IOBluetoothDevice.closeConnection
returns successfully but does not close anything. In blueutil they have fixed it like this.When I use
--disconnect
combined with--wait-disconnect
it consistently works to disconnect.I hope this information helps with fixing the problem.
Steps To Reproduce
No response
Current Behaviour
No response
Expected Behaviour
No response