deanishe

There's a configuration file called client_rules.json in the workflow.
 
Change "names" from true to false on line 78 in the MS Outlook config.

I can't help you if you can't give me something more concrete to work with than "not working".

This is great. Glad to see so much discussion and careful thought around this issue. Thanks @deanishe for your explanation of the subprocess / PATH issue. And thanks to @vitor and of course @Andrew as well.
 
I agree with the concept of a per-workflow: [x] Enable Homebrew support checkbox that sets  PATH  and  HOMEBREW_PREFIX . That seems like a really low-impact way to provide this functionality without affecting anything for existing users or people who chose not to use it.
 
 
Actually it doesn't ignore it—I've run into trouble once or twice by overriding  PATH  and forgetting to include a necessary dir.
 
Example:


 
(Script:   echo $PATH )
 

 

Sure, the variable will still be set, but nothing will actually pay any attention to it, will it?
 
Let’s say you run $HOMEBREW_PREFIX/bin/youtube-dl. When YTDL wants to call FFMPEG, it doesn't consider $HOMEBREW_PREFIX or its own path. It just runs the command ffmpeg, so if you haven’t altered PATH to include $HOMEBREW_PREFIX/bin, where ffmpeg is, the call will fail.
 
In situations like this, you will need to do export PATH=$HOMEBREW_PREFIX/bin:$PATH

It could go one further and allow specifying the dependency names. On Workflow install it could check for the existence of those packages and show a message if they’re not installed:
 
“You’re missing dependencies for this Workflow. Install them with:
 
brew install pkg-name”
 
If the user does not have Homebrew, an extra sentence:
 
”To learn more about Homebrew, visit https://brew.sh” (or an Alfred documentation link).

On the message there might be a way to disable the Homebrew requirement and continue using the Workflow, for advanced users. Still have to think of the advantages and drawbacks of this one.
 
I though of the possibility of the requirements being binary names instead of Homebrew package names. The advantage of the former is that a user doesn’t truly need Homebrew installed, just the binary, but Homebrew package names don’t always map exactly to package names (making the automatic dependency message harder). Specifying the package name, on the other hand, allows for specific versions and taps to be set.

If the goal is making using Homebrew programs easier, an option in each workflow's configuration to activate Homebrew support might be the best solution. Alfred could then alter the PATH passed to the workflow to include Homebrew’s bin directory.
 
That should make Homebrew Just Work for those who need it, without any unwanted side-effects for those that don't.

You won't have any issues as long as you're building workflows that are only interesting to other people who have the technical skills needed to install the workflow's dependencies.
 
It can just turn into a support nightmare with workflows that also appeal to non-technical users.
 
It's just a bit of a shame to my mind that you've written such a powerful library, but made it impossible to build workflows that work out-of-the-box with it.

Define "rare". I mean, workflows for Ruby developers isn't exactly a large category, and most people writing any other kind of workflow in Ruby have the sense to stick with the system runtime. Requiring a non-standard runtime is a pretty user-hostile thing to do, and we've all seen what a support nightmare it becomes.
 
The Node crowd – as JS devs are wont to do – have gone in at the deep end in that regard, and 90% of every thread about a Node-based workflow is questions about Homebrew/Node/npm, not the workflow.
 
There's no getting around that if you're going to use Node, but all indications are that the majority of devs writing workflows in Ruby or Python value working out-of-the-box and not having to deal with endless requests for help with dependencies more highly than getting to play with the latest language features.

Right, then the script is presumably running just fine. As @giovanni is hinting, print() won’t show any text anywhere because you haven’t connected it to anything that shows text… Either plug it into a Large Type or a Show Notification, or change it to print('blah', file=sys.stderr), in which case the text will be shown in Alfred’s debugger.
 
Also, you probably want print('some text', end='') if you're not printing to the debugger, so there isn’t a newline on the end of the text.

Now you know my secrets. 
 

BunnySlut

Odd Finder error when I use a workflow that has a "Reveal File in Finder" block:
 

 
When I make my selection from the List Filter, I get this error message after several seconds:
 
"The “Show in Finder” service could not be used because the “Finder” application did not respond to a request for services."

Clicking "Show Application" caused Finder to appear several minutes later.
 
This was the only Alfred-related message in the console: 
 
Jul 23 16:17:38 BunnySlut com.apple.xpc.launchd[1]: Coalition Cache Hit: app<application.com.runningwithcrayons.Alfred-Preferences.423402080.423402086(501)> [4792]  
It seems like the issue has resolved itself, but I've never seen this issue before.

1Password has multiple shortcuts. Go check its preferences and make sure you don’t have ⌥⌘\ assigned there, too. On my machine, that’s the hotkey for 1Password mini.
 
Also, apps can't override each others' hotkeys. If two apps register the same hotkey, it's up to macOS what happens.

Taking a bit of a deep dive into this, I'm not going to change the behaviour for 4.5 as it's more significant that I had plucked off the top of my head. Alfred does certain logic based on file types (e.g. running AppleScripts instead of opening them, opening Contacts inside of Alfred instead of macOS, fettling Folders when opening to help default sort priority). There would need to be additional logic to treat these files differently before opening the rest of the list in an updated compound way.
 
I do absolutely agree that this change should be made though, so I'll put it in the top 4.6 list.

Actually, this has never been the case on my side and I'm using the Large Type feature a lot as some kind of preview for my workflows that I've been popping and closing using CMD+L (pop) and ESC (close) and keeping Alfred always open so I can move to another result and preview it with CMD+L again...

But now that you say that, I see in the "Large Type" section in "Alfred Preferences -> Features" there's a toggle to "Auto Hide Alfred when showing Large Type" which should be active on your side... I find it very useful to have it unchecked so I can use the Large Type feature as a preview, but yes now I see that this could be a problem for this feature requests.

In the future, there will be significantly more control over which actions show for the context. I need to be completely happy with how it's working after 4.5 is released before adding more control.
 
 
You know, I can't actually remember - I'll add a note to look into this, as it's reasonably trivial to alter this behaviour.

https://www.alfredapp.com/help/advanced/sync/

Yes, fixed on my side with this build!
 
Look inside the "Action in Alfred" workflow object, there's now a "Jump to" section. This is used to directly "jump to" a specific action that has a second panel (ex: Open with..., Copy/Move to..., Open URL in...).

No, the “snippets” folder is inside the Alfred.alfredpreferences bundle. Right-click on it and choose “Show Package Contents"
 
That should be clear from the “Configuration” section on the page linked above. It's important to read carefully if you're a noob.

I've now popped a new beta build up with some fixes and improvements, available here:
 
https://cachefly.alfredapp.com/beta/Alfred_4.5_1240_beta.dmg
 
A quick summary of the changes:
Updated Script Filter JSON to now allow for overriding the arg with a new actions key to define the selected result action items See the Script Filter JSON help page for more details: https://www.alfredapp.com/help/workflows/inputs/script-filter/json/ Improved multiple argument support Improved argument type detection, including when calling from AppleScript Added new optional AppleScript "as type" so you can force to types "text", "url", and "file", e.g. tell application id "com.runningwithcrayons.Alfred" to action {"~/Desktop/", "~/Pictures/"} as type "file" Alfred will automatically detect the argument type if you don't explicitly define the type Fix Workflow File Action trigger to correctly respect the + file type tree prefixes [regression] Added Universal Actions preview panel for when there are multiple types of objects selected (will be improved in future) Improved Universal Actions view when multiple text items are selected (preview panel will be improved in future) Fix Alfred to respect WebURLsWithTitlesPboardType on clipboard when copying multiple URLs Fix fn/ctrl action tap in Clipboard view Tweak summary text on Actions Panel view Updated "Accepts Multiple" option in File Action Trigger and Universal Action Trigger to also allow for "Only Multiple Items" Various other tweaks and improvements, with detailed change log to come when the Pre-release is uhh... released.  
Thanks for all your help and suggestions so far with testing, if you could let me know if any of the things you've raised so far which should now be fixed are still not working, that would be ace
 
Cheers,
Andrew

Hi @Ilya Belsky, welcome to the forum.
 
It sounds like an encoding problem. I've rewritten the workflow in JavaScript. It should work fine with Cyrillic now.

Not to detract from your main question, but there is a non-official dropbox client that uses the official public API and therefore doesn't suffer any device limits: https://maestral.app

What you're asking has quite a few moving parts, and Alfred can't help with any of them (apart from moving the files).
 
You need something to monitor your folders for new files (Hazel? A LaunchAgent? A Folder Action if Automator can still make them?), something to identify the new file(s) (unless you always delete files after mailing them), an email client with an API that supports composing new messages with attachments (which is fairly rare), and finally a script that uses the API to compose and send the email. And then trashes the files, so they don't get sent with the next email to that person.
 
Finally, you probably want some mechanism to map each folder to a recipient. Writing a custom script for each person's directory would be a real pain.
 
The critical question is which email client are you using? If is doesn't have the right API support, you can basically forget it.

Hey All
 
Just wanted to let people who were having issues connecting the extension with the workflow as documented here https://github.com/deanishe/alfred-firefox/issues/15 that I was able to get it to work by moving the alfred backup folder to my dropbox directory. The backup folder was originally placed in a directory that synced with icloud and also had a weird long name (e.g. "3 resources and things"). I'm not a coder at all but kinda felt that if the worklow can't find server.sh, etc... that it might have something to do with the folder length, naming, or icloud.
 
Anyway, thanks Deanishe for this contribution. It really makes life easier!

For completeness, one more way to find an app’s path from the bundle identifier: mdfind kMDItemCFBundleIdentifier = com.runningwithcrayons.Alfred.