deanishe

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…

I'm not a big fan of the external triggers method, as I prefer to keep as much of the complexity as possible in my code, where I can comment it, and out of Alfred's UI where it can be difficult to maintain an overview of which element does what (it's not possible to show a connection between a run script action and the external trigger it calls, for example). It's also a lot easier to refactor a workflow in a code editor than in Alfred's UI. What I'd do in this situation is to create a "multi-level" query using a delimiter, e.g. 〉, and show results according to the query. Thus, tlo would show a list of all boards. Hitting ENTER or TAB on a board would autocomplete the query to 'tlo board name 〉 ' (note the trailing space—it's important), and your script filter would then show a list of that board's lists. 'tlo board name 〉 blah' would filter the board's lists on blah. Hitting ENTER or TAB on a list expands the query to 'tlo board name 〉 list name 〉 ' (trailing space again) and your script filter shows the contents of the list and so on. The trailing space is important because you can use that to jump back up a level: if the user deletes the trailing space (i.e. the query now ends with 〉, you pop the last level off the query and go back to the previous list. Carlos's Recent Items workflow uses this technique, as do my Smart Folders and Packal Search workflows. My workflows might be of more use to you as a guide, as they're written in Python (which I think you're using, too).

I don't use Anki (the price of the app on iOS is ridiculous), but I use flashcards a lot (I had about 10,000 last time I looked). What I do is create the lists as TSV (tab-separated) files in a text editor and have a script to convert the TSV files into an importable format, e.g. .studyarchive files for Mental Case or a differently-formatted TSV for Flashcards Deluxe. It's hard to imagine a more efficient input interface than an editor, and I think it'd be a better investment of time creating a syntax definition for an editor than trying to coerce Alfred into working as a flashcard editor.

This workflow of mine does the same thing.

That's much nicer. I can never remember where the & goes in the longer form…

This is a common problem with all Java apps (at least all the ones I've used). My guess is that Java's own internal clipboard doesn't do a great job of shadowing the system pasteboard. It makes using apps that fiddle with the pasteboard, e.g. TextExpander, a bit of a crapshoot in Java apps. With such a short snippet, you might have more luck using AppleScript to "type" the timestamp for you instead of using the pasteboard.

It's not a problem with the mvim script, it's due to the way Alfred runs scripts. Alfred (correctly) doesn't consider a script finished while its STDOUT and/or STDERR are still open (i.e. there may still be some output to come), so to get Alfred to consider a backgrounded process finished, the process has to disconnect from or close STDOUT & STDERR: MVIM=/usr/local/bin/mvim case "{query}" in "h") cd ~/ && $MVIM > /dev/null 2>&1 ;; "d") cd ~/Downloads && $MVIM > /dev/null 2>&1 ;; *) echo "unknown directory specified" ;; esac

Don't know much about schemas personally. I try to avoid XML where possible. AFAIK, if you wanted to host it on GitHub, it'd have to be JavaScript-based. There are a few things missing there: `arg` can be an element as well as a attribute. The `text` (`copy` / `largetype`) element is missing, too, as is the root `items`. I wonder about the utility of a validator, however. Doesn't everyone use a workflow library to generate the XML? And Alfred's XML format is very simple, as these things go.

Chances are you just need to update the youtube-dl script within the workflow. Looky here.

The idea of cached_data() is to avoid generating/fetching data if the cache is up-to-date. So, instead of passing it the data it should cache, you pass it a function it can call to get fresh data if the cached data is too old/non-existent. You're passing the results of a call to getBoards(). You need to pass the function itself, which cached_data() will then call if necessary. Normally, that looks something like this: def fetch_new_data(): # grab data from a web service/app here # ... return new_data data = wf.cached_data('cache-name', fetch_new_data, max_age=600) Note that I'm passing fetch_new_data not fetch_new_data() to cached_data(), i.e. the function itself, not the data returned from calling the function. You can't just pass the function in this case, however, as getBoards() takes an argument. Check out the example script here. Look at the wrapper function and the call to cached_data() (lines 82–89). Note that I pass wrapper to cached_data without calling it. You could also pass lambda api_key: getBoards(api_key) or functools.partial(getBoards, api_key). I wrote a separate wrapper() function in the tutorial to make it clearer and more explicit (lambda is ugly). Does that help?

I see you've deleted the thread for contributions regarding the documentation… The new Script Filter docs on support.alfredapp.com are much improved. A few observations: There's no mention that arg can also be a tag as well as an attribute. Also no mention of text encoding. Given how often that comes up on the forum as a problem, it surely deserves at least a mention if not an entire section. The "Escaping the XML" advice is also somewhat misleading, which is to say it implies that it's easy, which it isn't. A proper XML library should always be used. If an appropriate coding isn't specified (as in the example) and the XML contains non-ASCII characters that aren't properly encoded, bad things will happen. Escaping options (for the Script box) are not mentioned at all. These differ greatly between languages and the way those languages are used. If they aren't right, bad things will once again happen. No mention of how the various parameters interact. For example, what gets copied/large-texted if a copytext or a largetext isn't specified? The "Result Ordering and the UID" section of the Script Filter docs starts "It's worth iterating that Alfred learns usage of your <item> results …". I guess that should be "reiterating" or "repeating".

Agree 100% wrt keeping stuff in code and the utility of external triggers. If I want data from a webservice/app that will take a second or two to load, I usually go the background process route. But instead of having that process talk to Alfred, I show an extra result item notifying the user that the data is being updated and use cached data instead. Unfortunately, this means the user has to re-run the command to use the latest data, but I think that's better than Alfred randomly being called from the background, especially as the user might be trying to do something else with Alfred at the time. This is how I normally do it. The way I see it, this is a hard limitation with Alfred: the optimal solution just isn't available.

FWIW, there is a diskutil command line utility. It can do everything the app can and more. We already do tackle the workflows we think are beneficial. You'll have much better luck if you try to make the workflow yourself, putting the code up on GitHub, and then asking for help with specific problems you run into. We're much more likely to help you write a workflow that to write one for you.