Chris Messina

@Andrew Thank you for that detailed explanation. I understand why and how more than one Workflow can have the same hotkey combo and understand the cascading logic for determining which action hotkey combo gets actioned when triggered. I do have subsequent feedback: Once a hotkey combo is specified in one Workflow, I am unable to set the same hotkey combo in a different Workflow. This seems to conflict with the behavior you've said should be possible? I am unable to copy and paste a hotkey combo from one Workflow to another if the destination Workflow is disabled. It would be useful if "Related [Hotkey Combo]" information were contextually available/made more proximate to the "Shared with other hotkey triggers" orange text. I may have avoided going down this rabbit hole had I know that sharing a hotkey combo would cause a new menu item to appear which would reveal the Workflows that share the same hotkey combos. I'm also pleased to find that searching for hotkey combos in the Workflows Find feature actually works! I didn't expect that — but am glad to have learned about it!

Quick update: I was able to find the hotkey conflict, but it turns out it was in a disabled Workflow. Steps I took: Reveal original Workflow in Finder Open info.plist in Plist Edit Pro Search for "hotkey"; found "1835008" Grepped through ~/Dropbox/Alfred/Alfred.alfredpreferences/workflows but found that this was not a rare hotkey combo, so instead grepped for "<string>K</string>" Got two hits! Opened the conflicting Workflow and discovered that it was a Disabled Workflow. Unset the conflicting hotkey combo Not an impossible process, but certainly obscure — and even moreso since I didn't expect that disabled Workflows would be considered in conflict. As such, I've posted a bug report about that.

It turns out that you can have conflicting Hotkey Combos, even if a Workflow is disabled. It seems like disabled Workflows shouldn't be considered when looking for conflicts.

Hello! I searched across the forums and found a technical solution to locate hotkey combination conflicts, but I'm wondering if Alfred already provides an easier method (e.g. by listing the other Workflows with conflict in a ℹ️ tooltip?) or solution to locate and unset conflicts? I have over 200 Workflows so inspecting each isn't efficient; I'll use the grep method meanwhile, but a UI affordance that lists all hotkey combos and which Workflows contain them would be very useful.

Possibly, but .timemachine* doesn't actually exclude all those dated .backup files in my screenshot, which should be the intention (since those are Time Machine backups!).

🤦🏻‍♂️ Yep, that did it. Good catch! Thanks! Now I see: It does occur to me that @Andrew may want to update the exclusion list to include `*.backup`, since com.apple.TimeMachine* doesn't exclude Time Machine backups.

Afraid not. This is a clean install of macOS... I've been re-installing my apps one at a time, and haven't installed anything like that (that I know of). Here's the output of that command:

Seems to no longer work, but granted last time it was reported to was in 2015.

Here you go. As you can see, Alfred has access to and can see my Volumes. Similarly, Disk Utility can see all of my volumes too: I do no have any third party Finder extensions installed. The Eject command worked on my Intel MacBook Pro; it doesn't seem to work on my M1 MacBook Pro. I do/have synced my Alfred settings between both using Dropbox.

Love that idea!

This seems like a new issue since I've setup my new M1 MacBook Pro, but even though I have the "eject" and "ejectall" System commands enabled, they don't appear in my Alfred results. Any reason why this would be? (And yes, I had several external volumes mounted when I tried to execute this command)

If you check out Dash's workflow, it cleverly uses callbacks, and otherwise dynamically generates the plists for the Script Filters. open -g "dash-workflow-callback://{query}" It does seem like this could be a good model to emulate!

Like @andy4222, I'm a big fan of TextBuddy. I would like to be able to select some text, invoke Alfred's Universal Actions, then choose from the menu of available options supported by TextBuddy. More details: like many apps, TextBuddy has its own simply command palette: I've been in touch w/ the developer and we're interested in hooking up Alfred Universal Actions to these actions (e.g. having TextBuddy do the processing, possibly headlessly). @dfay's CaseConverter Workflow offers Text Actions: ...which implies that a TextBuddy Workflow would need to enumerate all of its Text Actions in order for Alfred to list them: — but I'm presuming that there might be a way for TextBuddy to generate a JSON List Filter or something like that would automate and keep-up-to-date that list of commands as they evolve in each app update. My question is really to support Tyler building a deeper integration with Alfred. Are there tips or best practices for app devs to advertise their services to Alfred's UA engine? Thanks!

Consider @dfay's fuzzylist. You might also like @Mr Pennyworth's alfred-lf2csv.

Very well then. I've expressed my preference. Happy to move on and consider my request moot. No worries.

Does this happen often? I understand your desire to mitigate issues with custom fonts and custom themes... but it seems (to me, you have the actual data) that the number of less technical users that will install a custom theme with a non-standard font (a process that opens Alfred's Preferences necessarily) is exceedingly small. More likely, especially in my themes that use non-standard fonts, the user won't have the requested font, and Alfred will fallback to a standard system font (I assume), so it's kind of a non-issue for most users? Your scenario becomes problematic where the user actually goes out of their way to install a custom theme AND problematic non-standard fonts, right? Sorry, not trying to be obnoxious — but personally I'd appreciate it if the Launcher UI's fonts were able to be completely consistent. The update text appears so infrequently that I'm not going to die on this sword, but I do think the rationale feels inconsistently weaker than other times when my proposals get shot down. 😜

I see that PHP Workflows are better supported in this case with Alfred 4.6. Can this be extended to Python2 workflows?

Ah ha — same issue! Posted about it here.

I've updated to macOS Monterey and just received this warning when launching Alfred. Tapping "Learn more" leads to this page announcing the sunsetting of Python 2. It would be helpful if Alfred helped me identify which workflow triggered this warning so I can either update it or disable it, perhaps by logging it to the Console or marking the workflow in the Workflow pane. Otherwise this warning is misleading:

@Andrew can do that — and probably should also see the UA sorting algorithm feedback in this thread.

Hmm. I understand your concern, but wouldn't a broken font affect Alfred's entire launcher UI? Why is software update notice an important exception? There aren't any other kinds of text like this, right? It's not a big deal, but given how important fonts are to my themes, I noticed that this seemed like an unnecessary deviation in theming...

Got it. I can't speak on behalf of @Andrew, but given the dynamic "learning" aspect of Alfred, it seems like manual sorting (unless you're using some kind of List Filter), isn't the preferred default behavior. Because Workflows can register new UAs, it's unclear what might happen to your sort order when they are added.

I can't tell if the "Alfred Update Available" is set in a font determined by the theme. There's no text styled this way in the Appearance preview, so thought I'd check. It's very minor, but would be nice if it were able to be set by the theme.

Does it help that you can type-to-find? Also, can you elaborate on how sorting your UA list would be useful?

Yay! Saw this in the Alfred 4.6 Pre-release (Build 1263) release notes!