deanishe

Does that actually make it work on Alfred 3? I figured that one would need a lot of work because it messes around with its own info.plist a lot. I haven't really got round to updating my workflows for Alfred 3 yet. I'm still digesting the new features and what I can do with them, and pondering how to alter the self-updating mechanism to prevent workflows running under Alfred 2 to update to Alfred-3-only versions.

AFAIK, that doesn't actually matter much without a "Show System Files" setting. It definitely is a little confusing, having a "Show AppleScripts" option when Alfred won't show any AppleScripts you keep in the usual script folders, which are all in ~/Library. Maybe. I'd argue it's a bug more than anything, as you can't even do it with the Powerpack. You need a workflow, too, because Alfred's File Filters don't work reliably with System Files. I can heartily recommend the Powerpack. Worth every penny. Mind you, I'm biased because I workflow the shit out of Alfred.

Secure SHell for Alfred 3 Open SSH/SFTP/mosh connections from Alfred with autosuggestions based on SSH config files, /etc/hosts and your history. Features Auto-suggest hostnames from ~/.ssh/* and /etc/hosts (sources can be individually disabled). Remembers usernames, so you don't have to type them in every time. (You can also remove connections from your history or disable it entirely.) Alternate actions: - Open connection with mosh instead of SSH. - Open SFTP connection instead of SSH. - Ping host. Data sources The workflow reads hosts from the following sources (in this order of priority): ~/.ssh/config History (i.e. username + host addresses previously entered by the user) ~/.ssh/known_hosts /etc/hosts /etc/ssh/ssh_config Installation Download from Packal or GitHub releases and double-click the file to install in Alfred. Source code is on GitHub. Usage Keyword is ssh: ssh [<query>] — View and filter known SSH connections. - ↩ or ⌘+<NUM> — Open the connection. - ⇥ — Expand query to selected connection's title. Useful for adding a port number. - ⌘+↩ — Open an SFTP connection instead. - ⌘+⌥ — Open a mosh connection instead. - ⇧+↩ — Ping host. - ^+↩ — Forget connection (if it's from history). Configuration There are several options available in the workflow's configuration sheet. Notably, you can turn off individual autosuggestion sources. Please see the GitHub README for details. Please note: The workflow generates an ssh:// (or sftp://) URL and asks Alfred to open it. Similarly, the ping and mosh features uses Alfred 3's Terminal Command feature. If it's not opening in the right app, it's not the workflow's fault. Licencing & thanks This workflow is released under the MIT Licence. It uses the following libraries and resources: The icon is based on Octicons by Github (SIL Licence). ssh_config (MIT Licence) to parse SSH config files. awgo (MIT Licence) for the workflowy stuff. This workflow started as a port of @isometry's Python SSH workflow to Go as a testbed for awgo. It has since gained some additional features. If you need Alfred 2 support, check out @isometry's workflow. Changelog v0.6.0 — 2016-11-09 - Add in-workflow updates v0.5.0 — 2016-10-31 - Add support for SSH configuration files (~/.ssh/config and /etc/ssh/ssh_config) - Alternate action: open connection with mosh v0.4.0 — 2016-05-27 - Add ability to turn sources of suggestions off #1 v0.3.0 — 2016-05-26 - Alternate action: Open SFTP connection - Alternate action: Ping host - Remember connections with usernames, so you don't have to type the username each time v0.2.0 — 2016-05-23 - First public release

Alfred's debugger will tell you more about what's wrong, but it's most likely an encoding issue. The XML header should be <?xml version="1.0" encoding="utf-8"?> And also make sure the XML is UTF-8 encoded. In fact, at this point, you should probably forget about XML and uses Alfred 3's JSON support instead. There are far fewer things you can get wrong with JSON. At any rate, if that doesn't help, you need to post the code that isn't working.

Depending on what you're doing, maybe changing info.plist is the right way to go. If a user can set their API key via the configuration sheet or a workflow action, it would be confusing for the API_KEY field in the configuration sheet to be empty. It's simple enough to change a variable with PlistBuddy: /usr/libexec/PlistBuddy -c 'Set :variables:API_KEY "api-key-goes-here"' info.plist

It should be possible to override icon in the mods section of Script Filter result items.

https://gist.github.com/deanishe/ce442c3a768adedc9c39

I don't think you can have anything in ~/Library in your default results because they're classed as system files. Either you'll need to use a File Filter with the Search Scope > Show files marked as System Files box ticked or a workflow like AppScripts, which can also show you just the scripts for the active application.

Yeah, I think the expectation is that users will use the configuration sheet to configure your workflow. You put the instructions in the About this Workflow box on the left, and the user has to fill in his/her API key/username/filepaths in the Workflow Environment Variables table. Alfred preserves a user's changes to the variables across workflow updates. The Workflow Environment Variables are read-only defaults, to be overridden temporarily at runtime by JSON Config and Args and Vars Utilities. The only way to permanently change the values of the Workflow Environment Variables programatically is to edit info.plist. That's generally a last resort, however. The usual way to persist user settings is to store them in the workflow's data directory, which is ~/Library/Application Support/Alfred 3/Workflow Data/<bundleid>, and available as the alfred_workflow_data environment variable. Assuming you're using the Script box like a shell, the simplest way to persist settings is, I guess, to write their values to files in the data directory and load them from your workflow script. That would override the Workflow Environment Variables and any JSON Config/Args and Vars settings. If you have multiple variables, you could write them in a file in "export" style and source it: Script filter: myvar="The early bird catches the worm" test -f "${alfred_workflow_data}/settings" && source "${alfred_workflow_data}/settings" cat <<EOS {"items": [ {"title":"myvar", "subtitle":"$myvar"} ]} EOS settings file: export myvar="But the second mouse gets the cheese" If you only have one or two settings, you could just write their values to files and load them via cat: test -f "${alfred_workflow_data}/myvar" && myvar="$( cat "${alfred_workflow_data}/myvar" )"

Any script would need to know which files to send to which person and what their email address is. How would it know which files go to which email address? Could you post a list of the actual filenames? Or a fake set of filenames that follow the same rules (e.g. with fake names)? I'm 100% sure the emailing and adding notes to Evernote stuff is doable. Even if it can't be done by scripting Mail.app and Evernote.app, sending an email via a mailserver is easy to do, and you can add notes via the Evernote API.

That doesn't really have an awful lot to do with Alfred. That is to say, Alfred can start the thing for you, but can't help you much otherwise. Hazel is more the app for kicking off actions based on files, but I don't think it could help much either. You're probably going to do 95% of the work in code. You need to look into scripting Evernote with AppleScript. You may be able to do it with JavaScript, too, a somewhat less insane language, but it's much harder to figure out how to automate apps with JS than AS at this point. Similarly, it also sounds like you want to automate Mail.app, and perhaps Finder, too. Fortunately, you can probably copy most of the code you need from other places. In particular, Carlos-Sz's Evernote workflow is written in AppleScript and can create notes. If you have more concrete questions, I can give you more concrete answers.

I'm not sure what you mean by "wasn't a first class citizen". On OS X? Node's status is the same as it ever was with regard to Alfred 3. Alfred doesn't care what language/platform you use for your workflow, as long as it understands UTF-8.

From my tests, it appears that Alfred doesn't expand (query), {query} or {var:…} macros in the "fields" object. A bug?

It works fine in Alfred 3 for me. Try reinstalling the workflow, perhaps?

I don't think it's possible using Run NSAppleScript. Alfred passes variables as environmental variables to its child processes, but NSAppleScript isn't run in a separate process, so no variables… Instead of Run NSAppleScript, use a normal Run Script Action with Language = /usr/bin/osascript (AS). Then you can access your variables thus: setvariable "alfred_build_product" to (system attribute "product")

Call the AppleScript tell application "Alfred 3" to search "hv new WCSSAA site → Template Creation and Editing" (Or "Alfred 2" if you're using v2.) That way you don't have to edit the target workflow.

Not possible, I'm afraid. You'd need to use a Hotkey and script to do that.

You can't. Currently, Alfred can do dates and times and insert the clipboard, but no other dynamic values are supported in snippets. You can't even place the cursor yet.

It's likely an issue with Alfred, then (seeing as the workflow and Python are working). Especially if you're having problems with workflows written in different languages. When you try to run a workflow, and nothing happens, could you check in Activity Monitor? Select menu View > All Processes, Hierarchically and see if Alfred 2/3 has any Python/Ruby child processes.

FWIW, you could use an AppleScript to get the path to the application: tell application "Finder" to get (POSIX path of (path to application "OmniFocus")) Not a good primary method (too slow), but perhaps as a fallback?

What do you mean by this exactly? The decorator would capture the output of some_function then call Alfred via AppleScript with the query spam <output>?

Luxinate is also a Python workflow. The repeated issue with workflows hanging wasn't a problem with Python or my library, but an Alfred bug that was fixed in the last release of Alfred 2. First thing is to figure out if it's an issue with Python, the system or Alfred. Try some workflows that you know are written in different languages. Mine are all in Python. Vítor's are Ruby. If none work, it's a problem with Alfred (or the system). If it's just Python workflows, let's test one outside Alfred. Open my Convert workflow in Terminal or iTerm and run it from the command line: /usr/bin/python convert.py "100 eur usd" If that works, it ain't Python that's broke.

No, the subl command still opens the project multiple times. If you open a *.sublime-project file with Sublime Text.app, it forgets which files were open etc. If you open *.sublime-project files with the subl command-line program, it opens the same files and directories as last time. I created a wrapper application so I can associate *.sublime-project files with it, so they're opened via subl even when I double-click in Finder or indeed via the Sublime Text Projects workflow.

Yeah, no go, I'm afraid. Although Sublime Text plugins (which run within Sublime) can do amazing things, Sublime isn't really scriptable from the outside. The closest you could get is looking at window titles (which are "XXX — <Project Name>") or by creating a Sublime Text plugin to work together with your external code. For example, I have a Sublime Plugin that writes the path to the current file to my home directory, so I can change directly to the directory open in Sublime Text from a shell. FWIW, my preferred solution for .sublime-project files is to open them with the subl CLI program. It opens projects with the correct files open, which the GUI app doesn't. What I did was create a simple application with AppleScript that calls subl and associate .sublime-project files with that application.

Just connect your Hotkey to an Open File Action? Script Filters are for generating/filtering lists of results for Alfred. If you run a Script Filter script on the command line, it'll most likely just spit out a bunch of XML. Here's a tutorial on writing Alfred Script Filters with Python. It assumes you already know what Script Filters are. Here's a tutorial on writing Sublime Text plugins with Python.