Update status continuously

[littke]

Hey,

Thanks for building a fantastic workflow 🤗

I had an idea... I am using this to connect to my Bose QC 35. And those don't want to connect unless they're in pairing mode. But it's not always obvious whether they are. So I usually just type blt [name of my headphones and connect.

And then I wait. I won't know whether I was successful unless I re-open Alfred type in the same command again.

I don't know if Alfred supports this but I guess I have two requests/proposals:

• Add a modifier key that connects to the selected device, but doesn't close Alfred
• Update the connectivity status of each device regularly (1s?) to see whether a connection was successful

Sorry if this is another annoying request from someone who should've submitted a PR... but my Python days are long gone — sorry!

Cheers 👍

[tilmanginzel]

Hey @littke,

first of all thanks for the kind words! :)

I like the idea. But I also don't know if it is possible in Alfred to wait for the execution of a command or continously update the result set until a desired state is reached. This was my first workflow so I will need to dig into it. Maybe @trietsch has an idea?

Maybe this feature could be configurable inside the workflow. I am not entirely sure if I would like to have the prompt open until my headphones are connected, which might take a few seconds — they already beep and a voice tells me Bluetooth connected. :)

Sorry if this is another annoying request from someone who should've submitted a PR.

No worries! Asking for a feature is never something to apologize for, as long as no one expects an immediate implementation. ;)

[trietsch]

Hey @littke, thanks!

Regarding your idea, it sounds nice indeed. I caught myself today doing the exact same thing (even though it says Bluetooth connected).

Easiest (and also very easy to configure for end users) is to just send a push notification stating the end result of the action. @tilmanginzel how does that sound?

[tilmanginzel]

That sounds like the perfect solution! :) This wouldn't interrupt anyones workflow, so a configuration is probably not even necessary. The notification could also be used for disconnecting devices, turning bluetooth on or off. That's a great visual feedback, if you might not be sure what just happened.

@littke What do you think?

[tilmanginzel]

If it can be used for all commands, here are some proposals for the texts:

• Connected to [device]
• Disconnected [device]
• Bluetooth turned on
• Bluetooth turned off

The last two are especially useful if someone uses the blt toggle command.

@trietsch Do you want to give it a go some time or should I try? :)

[trietsch]

Great! Keen on what @littke thinks.

You can implement it if you want, I'll review :) Quite busy at the moment.

[tilmanginzel]

Alright. I should be able to find some time later this week, without any guarantees. ;)

[littke]

Haha wow. You're both not only kind, but appreciative of my input and you're thinking of starting on it almost right away. Jackpot! 🙌

In terms of the proposed solution, let me think...

I think the important piece is what happens if it doesn't connect. The "connection successful" is all fine and good... but sometimes my headphones are paired to something else (my phone? my ipad? my watch? my windows machine? I never know) and I just need more visibility as to whether it paired successfully to the Mac. And if it did not pair successfully, I think I'd like a retry feature. So something like:

Failed to connect to [device]. {Retry|Close}

And if you are implementing actions on the notification, you could even do that for the others (albeit less important):

Connected to [device] {Close|Disconnect} Disconnected [device] {Close|Reconnect} Bluetooth turned on {Close|Turn Off} Bluetooth turned off {Close|Turn On}

• = Autoclose after 3s (if Mac notifications allow for this feature)

Maybe that's a bit overkill...

Finally, I suppose that the timeout period is interesting to maybe configure... or at least know about. Like: how long does the workflow wait before it gives up? Just to inform the user, we could do something like:

Failed to connect to [device] after trying for 5sec. {Retry|Close}

Then we're really onto something 🙌

Thanks again!!

[tilmanginzel]

Hey @littke, good idea to include buttons into the notifications! I quickly checked, and the default Alfred notifications do not allow to use custom buttons. Luckily, this exists: https://github.com/julienXX/terminal-notifier

Using the terminal-notifier would have another advantage: We can use custom icons for each notification, so for example if the connection failed, we can add a small red x to it, or a green check mark if it was successful. :)

[littke]

Sweet. Let's do it.

Errr... I mean. You do it.

If you need any design stuff done though, I'm happy to help. Been designering for many years now.

I also don't check GitHub too often so if you need input on anything just ping @littke on Twitter

Cheers

[tilmanginzel]

So, unfortunately some bad news. terminal-notifier does not support action buttons anymore, which previously have been provided by alerter. Alerter features have been removed from terminal-notifier due to some issues, and apparently it's not actively maintained anymore. For example, there are open issues regarding memory leaks. Therefore I would not be comfortable in including it in this workflow.

I tried to find other possibilities to add actions buttons to notifications, and most articles refer to private macOS APIs, which might be unstable. In addition, I have zero experience with macOS development and its APIs.

@littke @trietsch Do you have other proposals for a retry feature? If not I would just go with the simple notification approach, which at least makes it quickly transparent what just happened. IMO it is still a useful tradeoff.

[tilmanginzel]

Some further reasearch led me to this: node-notifier, a Node.js module supporting cross-platform notifications with action buttons. :)

It could be complicated to include this into the workflow (but I assume it's possible). I am a JavaScript noob, so it might take a lot more time to get this working. Thus I will probably implement the "simple" notifications first, as an intermediate step. I will try to find some time in the coming week! :)

[littke]

👍

[tilmanginzel]

Hi @littke, @trietsch. I have added a pull request for the notifications. Here are some examples on how they look like:

The icon stuff turned out to be really difficult. I would have preferred to have just a single icon on the left, with an added checkmark or x, but this not easily possible without compiling multiple different versions of terminal-notifier. So I went for the solution to have a small content image on the right, which is supported out of the box. Most notifications now have an image to the right. My gut feeling was that this is counterintuitive for two results, so these have no image:

• Bluetooth turned off
• Disconnected device