deanishe

That should work. That's what I was getting at in my previous post.

So, I love the idea of this workflow, but I have an absolute requirement before I'll consider using it: I need the torrent component to run on a separate Linux VM (which is connected to the Internet via a VPN). Is it possible to put the backend process on a "separate" machine?

I think if you want to use the JS eval() function, you kinda have to do it from JavaScript…

I'm not sure what it is you're doing exactly, but I quite like the server-hangs-around-for-a-bit model. It's still ready and waiting if you need to use it again straight away. Obviously that's not so great if it's hammering the CPU. I think it would definitely be handy if you could check a box in the workflow config that tells Alfred to send a signal to your workflow process if the user closes Alfred or otherwise aborts your workflow.

Alfred doesn't send signals. Andrew would have to add the feature to Alfred. If you have a server process running, it could use AppleScript to see if Alfred is active. I think that's about it, though. What's the exact problem needs solving?

When I hear a question like this, my first feeling is you might consider refactoring the workflow as a standalone background server daemon with a workflow script as a client. Alfred's workflow-execution model is based around short-running processes. Long-running workflows can cause problems, e.g. Alfred won't run your workflow again until the previous call has completed. The way I'd do something like this is to have a server/client architecture, and the server cleans up and shuts itself down if no client has connected in the last X seconds. The client starts the background server process if the server isn't currently running. All the state is in the server process, and you have a very lightweight—and fast—client script in the workflow that communicates with it (via HTTP/REST, a UNIX pipe or whatever). It's a much cleaner architecture and eliminates a lot of potential problems. If it's important for Alfred to inform your process when its window has closed, a more standard solution would be for Alfred to send a signal to the process (if it's still running), such as SIGUSR1 or SIGHUP. Sending and catching signals is a standard feature of most languages, and you wouldn't have to figure out some kind of interprocess communication between your tidy-up script and whatever other processes are running (which would probably end up being signals…)

If only … If you need the results from another Script Filter, your best option is to call the Script Filter's script directly, assuming it hasn't been pasted into the Script box. That's a fairly brittle solution, however, as the script might expect its own directory to be the working directory or want to use the alfred_* environmental variables for its own workflow. There could be a lot of messing around involved. Also, AFAIK, it's also impossible to predict the name of the directory Alfred will install a workflow in. I wish it used the bundle ID rather than user.workflow.SOME_RANDOM_UID. If you want to call a Script Filter from another workflow, you might have to search a lot of directories to find the workflow you're looking for.

+1

When you open a workflow that way, you're "stuck" in the workflow. To enter a normal query, you have to close and reopen Alfred. Basically, your choice is between opening Alfred with no history showing and having to enter \ to see it, or opening Alfred with history showing and having to delete the \ to enter a normal query.

Sure. Technically, it's actually telling Alfred to call itself with your query, but the effect is the same. Delete Alfred's default Hotkey in Alfred Preferences > General. In the Recent Commands workflow, add a Hotkey with the same key combination you use to open Alfred and connect it to a Run Script action set to /usr/bin/osascript. Paste the following in the Script box: tell application "Alfred 2" to search "\\" (Note, you need to use a double backslash to get a single backslash, as it's the escaping character.)

Hmm. The User Manual and Tutorials say basically the same thing. Perhaps I should clarify that a function should be passed, not called. I guess passing functions around is not a super-common thing to do.

Theoretically, if you can't wait for the Alfred update, you could create a "runner script" in another language that would accept {query} from Alfred, write it into your JavaScript, then run it with osascript.

BTW, anyone who hasn't see the bookmark in the demo gif "The Beach Boys Shred I Get Around" really needs to see it

That would certainly be more useful. The label could be shown instead of the interpreter path. My thinking wrt the tooltip is that it wouldn't require any modification of the UI as the user sees it. I would rather have a label, though.

The new Alfred documentation wiki provides additional information on the XML format (notably how parameters interact).

That would be deeply cool, but it would require some rejiggering of Alfred's "here's {query}!" model or some clever escaping by the workflow author. Presumably, in either case it would end up involving passing XML (or JSON) around, which is honestly not really any more difficult that generating it to send to Alfred…

So, this popped up over in the help forum, but this is a better place for it to solicit feedback, methinks. Currently, Alfred allows you to specify alternate subtitles for the result items returned by Script Filters, so that you can let the user know which action would be run. Looks like this: <item arg="/path/to/Ideas.txt" uid="/path/to/Ideas.txt" valid="yes"> <title>Ideas.txt</title> <subtitle>Open file</subtitle> <subtitle mod="cmd">Reveal file in Finder</subtitle> <subtitle mod="alt">Trash file</subtitle> </item> Whereby the Script Filter is connected to three different Actions. The suggestion is to turn the alternate subtitles "inside out" and add a <mod> (or <alternate>) tag that can override not just the subtitle, but any of the item's parameters (that make sense): <item arg="/path/to/Ideas.txt" uid="/path/to/Ideas.txt" valid="no"> <title>Ideas.txt</title> <subtitle>Search in Ideas.txt</subtitle> <icon type="fileicon">/path/to/Ideas.txt</icon> <mod key="shift" valid="yes" arg="/path/to/Ideas.txt"> <subtitle>Open this file</subtitle> <!-- the super-smart workflow has figured out the default app for this filetype --> <icon type="fileicon">/Applications/Sublime Text.app</icon> </mod> <mod key="cmd" valid="yes" arg="/path/to/Ideas.txt"> <subtitle>Reveal in Finder</subtitle> <icon type="fileicon">/Applications/Finder.app</icon> </mod> <mod key="alt" valid="yes" arg="/path/to/Ideas.txt"> <subtitle>Trash</subtitle> <icon type="icon">trash.png</icon> </mod> </item> This would have a few advantages: It's possible to set an item to invalid for if, say, you want to require an additional argument by default, but override that in alternate actions. Currently, an action is always valid or never valid (this was the starting point). You can change not just the subtitle, but also the title and/or the icon, providing more and better contextual information (don't forget, some users turn off subtitles) You can change the arg. This means you can avoid a plethora of Run Scripts/Open URL actions and instead generate alternate URLs (e.g. to different search engines) right in your Script Filter and connect it to just one Open URL action. The same goes for copying different representations of data (e.g. colours, emoji or other non-ASCII text) to the pasteboard. (This would also require Alfred to allow multiple connections to the same Action/falling back to the "bare" action if there isn't another connection for the modifier) By avoiding hard-coded actions, it makes it easier to allow users to configure workflows without having their changes overwritten by a workflow update (which necessarily happens to any user-added actions and connections in a workflow) It wouldn't make sense to be able to override all of an item's options (e.g. uid, copy text and large text). It strikes me (and Florian) as a powerful addition. What do you think?

To expand on that suggestion a bit: it could (should?) be possible to override any of the standard <item> values that make sense (I guess overriding UID wouldn't serve any purpose, seeing as the item still refers to the same thing, nor the copy/large text). So, I could change the title and/or the icon, too. As a trivial example, I could write a workflow that mimics the fallback searches (Google, Wikipedia, etc.), but when the user presses a mod key, the search would go to google.de or de.wikipedia.org instead of the English site. And I could show a different icon with pretty black, red and yellow (not gold) stripes atop the standard Google/Wikipedia icon.

Alfred's Run Script/Run NSAppleScript actions (and the lines connected to them) provide very little information about what's actually in them (action type and interpreter or the modifier key). When your workflow has a lot of such actions it quickly becomes hard to remember which one is which, so you basically have to double-click each one open till you find the one you're looking for. Navigating the actions would be a lot easier if Alfred showed a tooltip when you hover over an action, say, the Modifier subtext for connections and the (first few lines of) the Script box for Run Script actions.

+1 It would definitely be handy if Alfred showed a list of its history, so you at least see at a glance if what you want is in there.

This would be handy, but I think it's unlikely. As Alfred uses OS X's built-in search index, and that doesn't use Levenshtein distances, Alfred would have to keep its own index purely for that purpose. That's not super-complicated to do, but on the other hand it's not super-complicated to do, so a workflow that does it would be trivial to knock up.

Perhaps you could twizzle the <subtitle mod="cmd"> XML into a mod tag: <mod key="cmd" valid="yes"> <subtitle>My alternate subtitle</subtitle> <arg>my alternate arg</arg> </mod> Having (optional) alternate args would make it easier to, say, open URLs to different websites or copy different formats of dates/colours/whatever to the clipboard without having to wrangle half a dozen Run Script/Open URL/Copy to Clipboard actions. It'd also make it easier for workflows to manage their own configuration without having to re-write their own info.plist, which is not an optimal solution.

You can actually just pass the smb://server/folder URL to Alfred's Open URL action. That has the advantage of opening the link in whichever app you've specified as the default handler for smb links, too.

That's not possible, I'm afraid (at least not according to my tests). An item is either valid or invalid. If it's invalid, Alfred won't let you action it so modifiers will have no effect. If it's valid, Alfred will "action" it even if there's no action connected (i.e. Alfred's window will just close, but nothing will actually happen). If you're working with filepaths, you could work around it (File Actions still work for items whose type is "file" even if they are invalid). You could work around this (in a hacky fashion) by the default (no modifier) action reopening Alfred with the same query, but that'd probably be quite nasty. You'll probably have to rejigger the way your workflow works.

In my experience, this is something that can be a bit hard to get your head around. If you put your code up on GitHub or similar, I'd be happy to offer my help as someone with considerable previous experience of finding it a bit of a challenge…