deanishe

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.

This is simple enough to do with something like Dragon Drop (or just two windows). Instead of hunting around in the subfolders, go to the top-level folder and search for "kind:Audio". You should then have a list of all the audio files in that file tree. Select them and either drag them into Dragon Drop or into the top-level folder you have open in another Finder window.

I'll see what I can do, but I really can't make any promises regarding Yosemite: I don't install any major new OS version (let alone betas) until I'm certain all the apps I need for work run properly on it.

Glad it works for you, but that sounds like an OS bug. Still, Spotlight on German systems recognises the English names of apps, so maybe the bug is that it doesn't work without ever changing the system to English and not that it works in the "wrong" language.

Bugger! Could you try deleting your ~/Library/Application Support/Alfred 2/Workflow Data/net.deanishe.alfred-mailto and running the workflow again. If the error persists, could you email me the settings.v-1.4.1.json file in the above directory and your ~/Library/Preferences/com.apple.LaunchServices.plist file? With your files, I should be able to replicate the error and fix it. Which version of OS X are you using, btw? I'll PM you my email address.

Try running python mailto.py delcache from Terminal in the workflow folder. That will reset the settings and the cache and should fix the problem. Probably…

It should be fixed in the latest release: https://github.com/deanishe/alfred-mailto/releases/latest Let me know if it isn't (I can't replicate the issue here).

If you create a directory under the directory Alfred keeps its workflow in and add a valid info.plist to it, you've created a workflow. Alfred will pick up any changes you make, but that usually takes a few seconds.

I keep my workflow source code with my other projects and symlink them to the directory Alfred installs its workflows in. Here's the script I use to install/symlink workflows. If you want to use it, you'll have to install the docopt library and edit ~/.workflow-install.json.

It was my mistake. I didn't update my distribution scripts to add the version file to the distribution archive. Everything should be working again in 1.9.1. The same goes for the version on PyPI.

Added support for the Mailbox beta in v1.4. Unfortunately, Mailbox's support for the mailto: protocol is crap and it only accepts email addresses (no names).

I have at least 8 Gmail accounts and an iCloud one as well, I think. At any rate, it's not actually necessary to be able to send or receive mails, just to run the program in order to test the workflow. So, yeah, I could definitely use one of these "beta-coins" shimmy-tangs in order to test the workflow. I'm up to my neck in work at the moment, however, so I can't promise that I'll be able to fix 'er up this weekend. It shouldn't be a big deal (max. 30 minutes is my optimistic/naïve estimate), but if it is, it'll have to wait. Also, looking over the code, I'm almost overwhelmed by the urge to totally rewrite/refactor it. If I could easily understand what my own code is doing, I probably would have already… Comment your code, boys and girls. Comment it for a clueless person. Because you'll come back to it a year later, and that clueless person will be you

Thanks. Unfortunately, I can't test it because I don't have (can't get) the Mailbox beta. I will look into it properly when I can get a copy. There won't be "official" support until the app is released, however.

Unfortunately, guessing the language of a word is tricky and error prone. It works well when you have several words or sentences to work with, but not with just one word, which is the main use case of this workflow (it's a dictionary rather than a machine translation service). I mean, if I enter die, after, trainee, prise, rat, shooting or kindergarten, are those English or German words?