Chris Messina

I updated one of my Workflows and renamed a Workflow Environment Variable, which I happened to use in an Open URL block: The console reported success: [09:27:09.006] Product Hunt Toolkit[Hotkey] Processing complete [09:27:09.021] Product Hunt Toolkit[Hotkey] Passing output '' to Open URL ...but I actually got this mysterious error (-50) — and when tapping on the ❓, got a blank helper window: Suggestion: It would be great if Alfred caught these errors and reported that a Workflow Environment Variable was unset or missing, directing me to the offending block in the Workflow editor.

Noticed these updates in Alfred 4.6.3 Pre-release (Build 1282): Which looks like this when you create a new Run Script/Script Filter block:

In addition to @Vero's resource, there is a lengthy discussion about the removal of Python from macOS here:

Because the user would have to install Homebrew AND Python to make that a viable option. It's unclear if or whether @Andrew would be open to enabling integration of Alfred and Homebrew (i.e. detecting whether Homebrew is installed). For example, Alfred could offer to install Python via Homebrew if a Workflow attempts to execute a Python command, similar to Xcode's Developer Tools:

Here are my Hyperkey settings (not sure why you can't set Remap your caps lock key to f19): This is my Alfred setting: Once you configure Hyperkey, you should be able to just press "Caps Lock" when setting your Alfred Hotkey.

It is quite unconventional. What implication might this have on Alfred's dropdown list of Languages after macOS 12.3?

To be fair, I actually "figured it out" because I was DM'ing w/ @mcskrzypczak and was working to diagnose my issues. But I take your point. Just saw this — is your position consistent with this upcoming change in macOS Monterey 12.3 Beta?

Ok, thank you. As I said, since I don't follow Python closely, I just assumed that Alfred would use the latest version, but obviously that's not the case — by default. It might be nice if the information you shared about python2 vs python3 were available in an info button when selecting /usr/bin/python from the dropdown, or perhaps Alfred could indicate which version of python is being selected with subtext in the menu. I'm not sure I would have figured out why my script wasn't working without your guidance. As it stands, without some kind of disclosure, it seems like Alfred is implicitly endorsing the use of the system python library since there are no warnings that it's deprecated.

I expected that /usr/bin/python would be python3, but it turns out that (on my system) it's Python 2.7.18. A script that I'd like to use in a File Action requires python3, and selecting python from this list causes errors in the console. Is it possible to tell Alfred to use python3 to run the script?

This doesn't exist AFAIK, but you might be able to create a Workflow that limits the hotkey or snippet expansion based on which apps have focus (see "Focused App Variable" in that page):

Maybe @Mr Pennyworth could add this to his Cleanshot Workflow (if you're willing to try Cleanshot). Another way to solve for this is to attach a Folder Action (unrelated to Alfred) that runs an ImageOptim CLI script any time a new image is added to your Screenshots folder, which you can set by using this command: defaults write com.apple.screencapture location /path/;killall SystemUIServer This blog post about @vitor's TinyPNG Workflow may also be relevant.

Cool, thank you. I agree that Python seems the most useful/approachable. I've had modest success so far — though the syntax takes some getting used to. We'll see if I make some headway in 2022!

True! I use my Toolkits to typically remind me of what things are called so I can access deep links without having to navigate by loading various webpages or sifting through different nav conventions. I don't have an aversion to coding — and don't draw the line there. I would like to learn but I feel overwhelmed by the choices... Python, Swift, Go, Bash, JavaScript, AppleScript, web APIs, etc... and unfortunately I don't code enough to maintain what I do pick up along the way. I'd love to learn though and agree that I hold myself back by not being a more capable coder. Where do you suggest I begin, or is that too big a question? (Granted, this may be OT, but I'm still interested given the nature of my original question).

Ah ok, thanks! Do you have an example/sample with navigational hierarchy I could work from? Happy to jump in if can start with a sample! Yes, I do think it's a bug. Reported. I've updated my Workflow to use this technique. Much simpler — thanks! As I'm sure you know by now, I'm not a programmer/developer... so it tends to be easier for me to "visually program" with Alfred's block builder UI. That said, I'd definitely prefer to just work with a script that I can quickly edit and tweak, especially given all the Toolkits I've made for myself. I'm sure I'm not doing them in an efficient manner, but brute force has been my most effective strategy so far. ¯\_(ツ)_/¯

Easiest way to understand this bug, discovered in this thread, is this animation: In my OpenSea Workflow, I'm using an environmental variable to set my "Go Back" text. However, when I enter that List Filter, I can filter plain text Titles, but because I'm using an environmental variable substitution, it seems to cause that List Filter item to be omitted {var:goBack}. The value of the goBack environmental variable is '← Go Back'.

In my latest Toolkit Workflow for OpenSea (source code), I've used a set of List Filters to create a nested navigation structure: This means that you can start here: And then navigate into a submenu and then navigate back up the stack — for example, Settings: I have a couple questions: Since I want to be able to use my custom icons, I'm using List Filters, but is there another way I could achieve something similar, perhaps w/ a JSON file? Once I've entered a submenu, typing 'back' doesn't filter the available options as expected. Is that because the title is an environmental variable? Any other suggestions for how to more efficiently build nest navigation workflows like this?

You may also want to check out alfred-dark-mode-toggle.

Just released a new workflow that makes it easy to access OpenSea on the web via the opensea keyword. Get the Alfred Toolkit for OpenSea It makes it easy to get to different features of the site via Alfred.

Try using the Alfred Keywords Workflow. Just enter ? And the name of the action and you will see a list of available actions.

Super, appreciate the validation!

Ok — FWIW, here's a recording of what I'm seeing. https://www.dropbox.com/sh/ytxsarp7z62jwe8/AAD4VD0ye6Yn4-hRlOlL9REea?dl=0 You'll see a hotkey combo being triggered in the overlay, which is when I'm hitting ⌃⌥⌘K. You'll see that I can not actually set that hotkey combo when it's already used by another Workflow. Thanks for taking a look!

Ah you're right! I misread your comment. And yes, I believe that's also correct — e.g. that the hotkey combo is being triggered as you try to add it, which means it never reaches the widget. And given that, the logic that @Andrew specified seems even more obscure, which is what lead me here in the first place: I have two Workflows that interact with Kaleidoscope, one that I made and one that the Kaleidoscope developer offered. I wanted to use the familiar hotkey combo (⌃⌥⌘K) in the developer's Workflow, but it was unknownst to me already registered in my disabled Workflow. Since I didn't realize I had a disabled Workflow that already "claimed" that hotkey combo, I was going out of my mind to figure out where or which app might be using that hotkey combo outside of Alfred because I couldn't use that hotkey combo within Alfred. It was silently failing without any kind of error message to inform me that the hotkey combo I wanted to use was claimed by being intercepted by a disabled Workflow. I mean, this just doesn't make sense — and perhaps this is a bug? — but if you try to add a hotkey combo that's already assigned in a disabled Workflow, you'll be unable to register that hotkey combo in an enabled Workflow! Why would the disabled Workflow hotkey combo be triggered when I attempt to use that hotkey combo?

That makes sense but doesn't match my experience. I was specifically trying to setup ⌃⌥⌘K, which I'm pretty sure isn't used by Alfred. I agree, which is part of my feedback. I also feel like it's a false positive, which conflicts with @Andrew's perspective.

@beauwilliams interesting, thanks. I found Spotify Global Commands and it does exactly what I was looking for.

Yep, the information in the other thread invalidates this report, although I added some additional suggestions for clarifying the behavior of shared hotkey triggers!