deanishe

Very nice. And so fast. I will be using this a lot! I have one request: Seeing as the workflow's results all have a specific translation direction, could the results open the webpage for the right translation direction as well, instead of the generic EN <-> DE results (i.e. set source=deutsch or source=englisch instead of source=auto)? For example, say I type a query with matches in both directions: If I action the first result, which is DE -> EN, I would like to see DE -> EN results. Currently, the workflow always opens the bidirectional DE <-> EN results page, which means I get all the irrelevant EN -> DE results first and the EN -> DE examples instead of the DE -> EN ones I'm looking for. Would that be possible?

I can give you a prototype that does exactly this but with Excel files. No idea how easy it would be to adapt to Numbers:

Yeah, generally I don't think silent failure is the right default behaviour. It can be confusing and frustrating for the user.

Try looking in Alfred's data directory on your machine. I think there may be a bundled one. The ones posted on the forum disappeared because the fella who wrote them (David) hosted them on Droplr or something else temporary. It's possible they've been re-hosted. If you can't find one, I'll paste the one I have here (I'm not at my computer right now).

You should be able to disable the Hotkey by selecting the Hotkey field and hitting backspace (i.e. delete the Hotkey). Are you sure the alternate Hotkeys you tried to set aren't already assigned to something (which will cause Alfred to reject them)?

I'm using the exact same version of Alfred and iTerm. Absolutely no problems expanding snippets from Alfred, Typinator or the system. There are a few things that can cause snippet expansion to stop working. The most common cause is that some application has enabled Secure Input mode (for typing in a password) and didn't disable it again afterwards (Chrome has always been terrible for this). This prevents any snippet expander apps from working because they can't monitor your keystrokes. First-rate snippet expansion applications, like Text Expander or Typinator, tell you if Secure Input is enabled (they can't fix it, but they'll let you know why they aren't working and which app caused it). Unfortunately, apps that just "feature" snippets (Alfred, Dash, Keyboard Maestro etc.) don't: they just silently stops working. Another possible cause is some OS X subsystem hanging or getting mucked up. The solution for both is to reboot.

Snippet?

It's not an Alfred error, though, is it? You're running bash. If it can't find the command, try telling it where to look.

What does the debugger say?

You have it all wrong. Go is a compiled language. You do not run your workflow with go run main.go. go run is a convenience when developing that compiles your program (in some temp directory) then runs it. It will crash and burn in Alfred because GOPATH isn't set. Instead, you compile your Go program with go build and run the resulting executable program from your workflow. GOPATH and GOROOT are just for development. GOPATH tells Go where to install libraries and binaries, and where to look for them when you import them. Before you can import any libraries, you have to go get them first, so they (and their dependencies) are available locally. Once your program is compiled, none of that matters. Go programs are always statically compiled, so it will run on any Mac regardless of whether they have Go installed. You need to go get ... any libraries you want to use. fmt.Println() doesn't work because it writes to STDOUT, whereas console.log() writes to STDERR. If you write anything but JSON/XML to STDOUT, your Script Filter won't work. You need fmt.Fprintln(os.Stderr, ...), though log.Println() is probably a better choice. The reason it's "complicated" is because you're trying to figure out two things at the same time. How Alfred/workflows work, and how to program. That is to say, you don't know what you need to do, nor how to do it. That's a hard place to be. My advice is to pick one language (Python or Ruby) and learn it. Read Dive into Python and How to Think Like a Computer Scientist (I'm sure there are Ruby equivalents). Go is a great language, but not a great first language. In particular, almost everything written about it (docs, tutorials, books etc.) assumes you're an experienced coder and know what things like mutexes and pointers are. Start by looking at other workflows to see how they do stuff, and try adapting them.

In Go there are only static binaries. You only need to "go get" dependencies in order to build, not to run.

Set $GOPATH to $HOME. Make sure you have ~/bin, ~/src and ~/pkg directories. That way, anything you go install will be put in ~/bin, which should be on your PATH.

Yeah. I know a bit about the GFW. Where I live and work, there's some blocking going on. I have a VPS running Streisand to get around it. That's why I recommend the SSH tunnel + HTTP proxy on the VPS method (if you have a VPS and can install a proxy) for this case. The SSH tunnel should get you past the GFW, and as I said, getting workflows (and many applications) to use an HTTP proxy is way simpler than SOCKS because support for HTTP proxies is transparently built in to Cocoa/Python/Ruby etc. Streisand also has a SOCKS proxy as well, but I usually find SOCKS really hard to work with. It's not SOCKS itself, which is perfectly simple, it's finding software that supports it in the first place.

http://www.alfredforum.com/topic/4533-list-filter-and-activate-network-locations-from-within-alfred/

Yes. Trying to call one workflow's scripts from a different workflow is extremely likely to cause problems. If you want to use one of Alfred's built-ins as a source for your script, e.g. a File Filter, you can forget about it. If you're in luck, Evernote exports its database under ~/Library/Caches/Metadata/ where other applications (and File Filters) can access it. If not, assigning the same keyword to multiple Script Filters is probably the only way to avoid a lot of work.

First of all, I'd report the behaviour as a bug in the appropriate forum. Seems to me that QuickLook should work if arg is a path/URL, even if it's encoded in JSON. What you can do in the meantime is set arg to the URL and save the other data to a temporary file (e.g. JSON), which the next action can load again. Every workflow has its own data directory (its path is in the alfred_workflow_data environment variable) for this purpose. Regarding the SOCKS proxy: Where is that running? Do you have your own VPS somewhere? If so, have you thought about setting up an HTTP proxy server (e.g. squid) on it and creating an SSH tunnel to that, instead of using a SOCKS proxy? The advantage of this method is that HTTP proxies are supported by almost everything that speaks HTTP (unlike SOCKS proxies). You can configure the proxy system-wide in System Preferences > Network, or use it on an app-by-app basis. In particular, you can "convert" most workflows to use the proxy just by setting the Workflow Environment Variables http_proxy and https_proxy in the workflow's configuration sheet. Languages like Python and Ruby, and programs like curl will automatically use the proxy. If you have a system-wide proxy set, Alfred automatically sets http_proxy and https_proxy for you. If you have a lot of workflows you'd like to route via a proxy, you should definitely look into tunnelling to an HTTP proxy. It'll be a lot easier than trying to add SOCKS support to every individual workflow.

Use the same keyword for both? If that doesn't work, then you'll probably need to write your own workflow that wraps the others.

QuickLook only works when arg is a URL, not a JSON object. Arguably a bug in Alfred. Note that your workflow is broken in at least two ways. The alfred.py library is very old and out of date. It has Alfred 2's data and cache directories hard-coded. If you don't change them, the workflow will fail for anyone that still doesn't have their old Alfred 2 directories. Also, you should be using json.dumps(...) to create your alfredworkflow JSON object, not trying to build the JSON by hand. Sooner or later, the URL or title will contain a character that can't be written as-is to JSON (a quotation mark, non-ASCII characters), and your workflow will stop working.

Create a new directory for your project with a "src" subdirectory. Create a new, empty workflow in Alfred. Configure the workflow's name, bundle ID, icon etc. in Alfred's UI. Reveal the workflow in Finder. Move everything to the "src" subdirectory of your new project. Delete the workflow from Alfred. Symlink your workflow from the project directory: workflow-install -s src workflow-install script.

I symlink my own workflows. Your code belongs in version control, not in an .alfredpreferences bundle in your Dropbox. So that this works cleanly, for Python, I keep the actual workflow in a src subdirectory of the repo. That way, I can symlink the subdirectory to Alfred without the .git directory ending up in Dropbox, which isn't great. Also, building the workflow is as simple as zipping up the contents of the src directory. Keeps it nice and simple. When the repo root is the same as the workflow root, you have to be careful to exclude files during building. I've seen a few workflows that contained copies of themselves that contained copies of themselves that contained copies of themselves… because the author kept the built workflow alongside the source in his repo. With Go, because it needs compiling anyway, I write a build script that puts the completed workflow in a build subdirectory, which can then be symlinked to Alfred or (its contents) zipped into a workflow. I also keep all the code in external files and use Alfred's Script boxes like a shell to call the scripts. Alfred is a terrible programmer's editor, and you lose a lot of the benefits of git etc. if all your code is embedded in info.plist. This has the overhead of an extra bash process, but that's about 0.01s when it isn't loading your dotfiles. With regard to libraries like Alfred-Workflow, I don't think they're as necessary in Alfred 3 thanks to the ease of generating JSON compared to XML (at least in scripting languages). There's a lot more to AW than just generating XML/JSON, but with Alfred 2 you basically needed a library for the XML generation alone. Finally, I generally write my workflows as command-line programs. If you have environment variables mapped to command-line flags, you can do some really neat stuff with workflow variables.

I had a quick glance at the code. The slowness is mostly down to the use of sqlalchemy, which is big. It's an industrial strength library, not ideally suited to small scripts meant to run fast. I did a little bit of benchmarking, and it takes ~0.2s for sqlalchemy just to import on my machine (old but has an SSD). With Alfred-Workflow, you're looking at a minimum of ~0.1s before your code starts running (0.05s for Python to start up plus 0.05s till Workflow.run() calls your main() function). That means it takes over 0.3 seconds before workflowScript.py even does anything, which is a noticeable delay. To speed it up, I'd consider using peewee instead of sqlalchemy. It's much smaller, so will probably load noticeably faster.

Alfred provides the hash for the machine that's running the workflow in the alfred_preferences_localhash environment variable.

In theory, the following AppleScript should prepend $1 to the notes of the contacts currently selected in Contacts.app. Unfortunately, it isn't working right now on my machine (it updates the notes, but Contacts.app doesn't show the update). on run (argv) -- Quit if no note was provided if (count of argv) is 0 then log "No note provided" return end if set theNote to first item of argv tell application "Contacts" set thePeople to selection if (count of thePeople) is 0 then log "No contacts selected" return end if repeat with aPerson in thePeople set curNote to the note of aPerson if curNote is missing value then set curNote to "" set newNote to theNote & linefeed & curNote log newNote set note of aPerson to newNote log "Prepended note to " & (name of aPerson) end repeat end tell end run

Typically when your snippet expander stops working, it's because some application enabled Secure Input mode when you used a password field, and didn't deactivate it again. Snippet expansion apps like TextExpander and Typinator warn you when this happens, but I don't think Alfred does. Usually, you just need to quit the application that enabled Secure Input, but that's hard if Alfred isn't telling you which one it was. There's a list of apps that can cause issues at the TextExpander page I linked above. In my experience, it's usually my browser, especially Chrome, that causes this issue.

Heh. So obvious now that you mention it I love this. So simple to use. No need for an appcast.xml or other data feed.