Jump to content

Alfred AirPods Pro Connector


Recommended Posts

I think there's still one little bug in it for M1 Macs -- inn the "Connect to provided bluetooth MAC" step it specifies `/usr/local/bin` where M1 it will be under `/opt/homebrew/bin`.

 

Changing that seemed to get it all working for me.

Link to comment
15 hours ago, JakeS said:

I think there's still one little bug in it for M1 Macs -- inn the "Connect to provided bluetooth MAC" step it specifies `/usr/local/bin` where M1 it will be under `/opt/homebrew/bin`.

 

Changing that seemed to get it all working for me.

 

ah yes, i see it. thanks for reporting. it didn't show up in the source coz it's directly in the Workflow object, and i don't have a M1 to test. so, great that you caught that one. will update later today.

Edited by godbout
Link to comment
  • 5 months later...
  • 3 months later...
  • 4 weeks later...

Installed version 3.0.1 and this is the error I'm getting after installation:

 

[12:49:24.361] AirPods Pro Connector[Script Filter] Processing complete
[12:49:24.370] AirPods Pro Connector[Script Filter] Passing output '--connect 1C-52-16-D7-F4-6E' to Run Script
[12:49:24.371] ERROR: AirPods Pro Connector[Run Script] zsh:3: command not found: BluetoothConnector

 

Mac's running on Monterey 12.3.1.

Link to comment
  • 1 year later...
  • 6 months later...

@vitor this Workflow has been updated to be Alfred Gallery compliant last year in July. could it be added to the Gallery? it seems that now we can't post in the "Submit to the Gallery" forum and the Alfred Team picks up Workflows here. thank you!

Link to comment

Added! Quick note: I see that you’ve compiled and signed/notarised the blueutil binary. For security and transparency (most users arriving at the Gallery won’t have built a rapport with developers), we add a small note to the page when a third-party binary is included in a workflow. You can see it under the install/download buttons (see another example). If you’d prefer to instead remove the binary and use the Homebrew formula as a dependency (example), we can do that too.


There’s no wrong or right answer, though, it’s whatever you prefer. I definitely get the choice to include the binary so user’s don’t have to worry about the extra download.


By the way, you should be able to make a universal binary (instead of shipping two of them and having the conditional) with:

 

/usr/bin/lipo -create /path/to/arm_version /path/to/intel_version -output /path/to/universal_version
Link to comment
4 hours ago, vitor said:

Added! Quick note: I see that you’ve compiled and signed/notarised the blueutil binary. For security and transparency (most users arriving at the Gallery won’t have built a rapport with developers), we add a small note to the page when a third-party binary is included in a workflow. You can see it under the install/download buttons (see another example). If you’d prefer to instead remove the binary and use the Homebrew formula as a dependency (example), we can do that too.

 

good point. and very fair. thanks for the info.

 

4 hours ago, vitor said:

There’s no wrong or right answer, though, it’s whatever you prefer. I definitely get the choice to include the binary so user’s don’t have to worry about the extra download.

 

well that was making sense for me to bundle it in the Workflow when it was only available from me and through GitHub, so that users had nothing to think about. but with the Gallery uniforming the Workflows installs, maybe users will get used to those notice about having to install the dependencies or that some dependencies are already bundled. so that changes things a bit and i'll have to rethink what's the best now. will depend on what i plan for the future, but my first feel is that the Gallery is the first place to go for Workflows, so that will influence my choice quite strongly. thank you! those notices are super welcomed.

 

4 hours ago, vitor said:


By the way, you should be able to make a universal binary (instead of shipping two of them and having the conditional) with:

 

/usr/bin/lipo -create /path/to/arm_version /path/to/intel_version -output /path/to/universal_version

 

ha excellent, thank you again! haven't touched those Workflows for a while and moved quickly onto other things. so great new knowledge. will digest, and most probably end up updating the Workflow. thank you again Vitor!

Link to comment

Should also be worth considering joining both workflows together for the next version, so people only have to install one. Or (I just thought of this while writing the previous sentence) even having a Script Filter that both shows the battery and allows for connecting and disconnecting (you shouldn’t be able to know battery levels anyway when AirPods are disconnected, I’d guess).


If you have an alternative icon, that would be helpful to further differentiate from the other AirPods workflow too. It surprised me a bit when I downloaded the Connector yesterday, as the icon in the notification was different from the one in the workflow.

Link to comment
6 hours ago, vitor said:

Should also be worth considering joining both workflows together for the next version, so people only have to install one. Or (I just thought of this while writing the previous sentence) even having a Script Filter that both shows the battery and allows for connecting and disconnecting (you shouldn’t be able to know battery levels anyway when AirPods are disconnected, I’d guess).

 

could be an idea. i'd have to (re)think about why i built the Workflows in the first place, and the current situation. i think i've built at least the Connector one because a few years ago the auto-detection/switch to other devices thing wasn't working properly, and you had to force the connection of your AirPods. tbh i haven't found myself using this Workflow for a while. i use the Battery one quite often tho. so yeah, really, could be an idea, but need to see if it's worth having that Connector at all first actually.

 

i'm not 100% sure either about the link between connection and battery info available tbh. if i remember well it IS actually possible to read the battery info without the AirPods being "activated". did a quick check tho and doesn't seem so 😂️ so yeah, would need to dig more.

 

6 hours ago, vitor said:

If you have an alternative icon, that would be helpful to further differentiate from the other AirPods workflow too. It surprised me a bit when I downloaded the Connector yesterday, as the icon in the notification was different from the one in the workflow.

 

a few points on that one:

1. so in the Alfred Gallery i see one other Workflow but 1) my Workflow is older 2) my Workflow specifically says AirPods Pro and has the icons of AirPods Pro while the other one is "AirPods" and has the icon of the Pro models 😂️ so i think it would be fair for the other Workflow to update/change their icon, if necessary?

2. oh what do you mean by the notification having a different icon? for me the Workflow itself, the Alfred Result, and the macOS Notification all have the same icon, the one that is packed with the Workflow.

 

thanks again Vitor.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...