deanishe

Your workflow doesn't have a version number. You also need to change the name of the program in L100. Your executable isn't called "update".

You want ControlPlane.

The first question to answer is whether Spark actually provides a mechanism to programatically add attachments (via AppleScript or a URL scheme etc.). If it doesn't, you can forget about it.

If you want help with a workflow, please upload the entire workflow somewhere and post a link to it. Unless the issue is super-obvious, we're not going to be able to figure it out without running the code, and it's unreasonable to expect us to try to recreate your workflow from a single script in order to help you. That said, you aren't actually reading anything from the input argv. Assuming you've done everything else right, you probably need something like set theDelay to item 1 of argv.

I've looked into this, and setting a location and radius for the Place search should get you the results you want. I've pushed an updated version to the develop branch with GOOGLE_PLACES_LOCATION and GOOGLE_PLACES_RADIUS options in the workflow configuration sheet. You must set both for it to work, and the location must be in decimal format, e.g. 51.450833,7.013056, and the radius is in metres. You must also delete your existing search and re-add it (or edit the config by hand to add the parameters to the URL). You can delete the search via the searchio command (it shows an error, as the feature isn't complete, but it does delete the configuration), or you can remove it by hand by entering searchio workflow:opendata and removing the corresponding file(s) from the searches directory.

I have a couple of ideas. Give me a day or two to see if they're doable.

Not precisely. From the API docs: https://developers.google.com/places/web-service/autocomplete#location_biasing So, it should prefer results near to you. It is possible to specify a location and radius. I guess I could add those as options in the configuration sheet if the geolocation via IP address sucks.

If you can figure out Kingpin, you can figure out how the updating works. TBH, Kingpin is overkill for such a simple workflow (it's for programs with lots of commands and options). It might have been a better idea to copy and adapt the update example workflow. Code-wise, you'd only need to replace the placeholder code that generates dummy results with your own code to parse your CSV into Items.

Everything installed by Anaconda works fine. As you've seen, Scripts that expect a properly-configured system, and aren't installed via Anaconda, don't work. See my earlier post. It works fine. You'll only have problems if you're on different branches on the different machines. If you're only going to symlink the workflows on one machine, there's little point even having the code on the other machine: you can't really work on the workflow because if it isn't linked, it isn't installed in Alfred.

Have you tried to understand the source code of notify.py? The code is very easy to follow, and well commented. The only function you need to call is notify.notify(), which installs Notify.app if it isn't already installed. If you want to use notify.py without Alfred-Workflow, you only need to replace the bits that call Workflow, which is only used as a convenient way to get a Logger and the path to the workflow's data directory. And FWIW, Notify.app is just a simple AppleScript saved as an application, so notifications show the app bundle's icon, not an AppleScript one (install_notifier() changes the icon of the installed Notify.app to that of your workflow on install). Here's the AppleScript (from Notify.app/Contents/Resources/Scripts/main.scpt): -- -- Copyright (c) 2015 deanishe@deanishe.net -- -- MIT Licence. See http://opensource.org/licenses/MIT -- -- Created on 2015-11-26 -- on run (argv) -- Grab variables via shell script as non-ASCII text doesn't work -- when read directly in AppleScript. UTF-8 text works properly -- this way. set theTitle to do shell script "echo $NOTIFY_TITLE" set theMessage to do shell script "echo $NOTIFY_MESSAGE" set theSound to do shell script "echo $NOTIFY_SOUND" log "Title : " & theTitle log "Text : " & theMessage log "Sound : " & theSound if theSound ≠ "" then display notification theMessage with title theTitle sound name theSound else display notification theMessage with title theTitle end if end run

Ho ho. This is totally awesome! I love that it picks up individual TTYs, and not just iTerm tabs (I tend to always run split tabs, with a shell on one side and a test server on the other). So good!

If Alfred is finding other files in /usr/local/Cellar, the problem is probably that no application on your system has defined a filetype for *.conf files. You could create a dummy application that defines the filetype in its info.plist, but the simplest solution is probably to add an "lftp" Keyword to a workflow and connect it to an Open File action pointing at the lftp config file.

And can Alfred now find the file?

The File Types are UTIs, not glob patterns. Try dragging a .conf file to the list. It may or may not work, depending on whether there is a UTI defined for file extension .conf

Because you submit a pull request against source code, not the binary… External triggers live in info.plist. Accepting binaries in pull requests is not a smart thing to do. There could be anything in there.

You can drag applications from Alfred's results list, too. That's a lot faster than using a file dialog.

Why don't you submit a pull request after you've added external triggers?

The same applies to quite a few workflows. I think the best solution would be for Alfred to define a double-modifier (e.g. ⌘⌥) that shows the subtitle. Or, you know, turn subtitles back on if you use features/workflows that really need them.

Like I say, if the "python" command on your system points to Python 3, you're going to have problems with it. Python 3 should be called "python3".

They go in ~/Library/Application Support/Alfred 3/Plugins/Email I don't know anything about writing one, though.

Attaching files isn't a "standard" feature like addressing emails is. It requires an AppleScript plugin for the specific email program you're using. There was a plugin for Outlook, but I've no idea if it's still available or works with current versions.

If they're all in the same directory, or there aren't many templates, a File Filter would be simpler.

Your best bet is Alfred's 1Password integration. If you create a 1Password login for each account, you can launch them from Alfred. Regarding this and your other question on Outlook: Alfred is a launcher, not an automation application. It's for finding and launching things. The limit of its integration with other apps is (generally) passing them some data via macOS. You can create a script that does whatever with your application, and Alfred can run it (and pass it some data), but fundamentally Alfred doesn't know how to do anything with other applications other than pass them some stuff.

Hi @CincyTriGuy. Welcome to the forum. I'm afraid you're probably asking in the wrong place. This is 95% an Outlook question, not an Alfred one. That is to say, what you're talking about is automating Outlook, not Alfred. Alfred can certainly pass the selected files in Finder to your script that does all the Outlook stuff, but it can't help you with any of the Outlook stuff… The same is likely true of the forum members. You'd probably do much better to ask on Think Different or a forum dedicated to Outlook/Office. It's possible there's an Outlook automation expert lurking on this forum, but it's not their natural habitat.

That's likely the cause of the problem. The script is built for the default Python 2.7 that's a part of macOS (/usr/bin/python). It works on any normal macOS install. It's almost certainly not compatible with Python 3. If you have other Pythons, changing the shebang to /usr/bin/python should make the script run properly. If the "python" command resolves to a Python 3 on your system, you should really fix that. "python", if present, should always be Python 2. Python 3 versions should be named (or symlinked to) "python3". The two are not very compatible, so having "python" resolve to Python 3 will break most Python 2 code.