deanishe

Alfred won't let you assign the same shortcut to multiple Hotkey triggers, even if their active apps are different. This is an unfortunate limitation that can make using the feature much harder. You have to connect the Hotkey trigger to an AppleScript that itself figures out which app is active and then takes the appropriate action.

I think you'd need to use /usr/local/bin/mpv, not just mpv, as /usr/local/bin won't be on your path in a workflow. (At least if you install via Homebrew. No idea where the default installer puts the mpv executable.)

You can't really write a workflow for Amphetamine because it isn't scriptable. The best you could do would probably to be to set Amphetamine to activate on launch and to create a workflow that starts/kills the application.

That does appear to be the problem. Alfred should recognise the file regardless, but the system can get confused if multiple apps declare conflicting UTIs for the same filetype, which is what's happened here. As your mdls metadata shows, it thinks your OPML file has a type of org.opml.opml (from the line kMDItemContentType = "org.opml.opml"). This is the correct UTI. Downcast, unfortunately and incorrectly, declares OPML files as being of the type downcast.opml, which is what Alfred has picked up on. As Alfred won't let you edit its File List by hand, the way I normally fix this (this happens with Markdown files a lot, too) is to open the workflow's info.plist file and manually change the UTI, i.e. change downcast.opml to org.opml.opml. It'd probably be a good idea to file a bug report with Downcast. The correct UTI is org.opml.opml and Downcast is causing the problem by clobbering this with its custom, wrong UTI.

What exactly is Alfred showing in the File Types list for your OPML document? There are a good few apps that make a real mess of OPML support on your system (Cloud Outliner is particularly naughty).

In all likelihood, that doesn't have anything to do with what you're doing. There's just a dodgy connection to YouTube.com. You could try making sure youtube-dl is up to date by running youtube-dl --update in Terminal.

Workflows are fairly simple (except for the coding bit) once you understand how the parts fit together. If you stick with it, I'm sure it'll click very soon.

This should do the trick: https://dl.dropboxusercontent.com/u/10123941/Safari%20Bookmark%20Folders.alfredworkflow Default keyword is "bookmarks". It'll show all the bookmark folders by default. If you enter a query, it'll filter the list of folders. If you select a folder (or type in its full name), you'll see a list of the bookmarks in that folder. One limitation: folder names must be unique. If you have multiple folders with the same name, only the last will be used. That's relatively easily fixed, but then you have the problem of multiple folders with the same name…

I've written a parser. If you tell me that the file exists on your computer, I can put it into a workflow for you.

"baffled by the build-a-workflow components" isn't a particularly easy problem to address. Can you be a bit more specific about what you're having difficulty with? If you don't know where to start, there are lots of tutorials available. The specific use case you want was talked about here.

Does the file exist or not?

What do you mean "the normal Alfred finder"?

Safari also provides a hierarchical list of its bookmarks at ~/Library/Safari/Bookmarks.plist.

What's the "ascii number" exactly? I mean ASCII only goes up to 127, so numbers above that must be for a different encoding.

Ah, that's how it works! I was typing "reload" and "refresh" and the like (typing commands is how the player otherwise works). Seeing as there is no such command, I assumed Alfred took care of that automatically, reloading the file when it changes. That seemed to be how it worked (I rarely use the mini player, so it often reloads the database when I do open it, which takes several seconds, which is why I rarely use it…) Everything seems to be working as intended now I'm holding the right end of the stick Marvellous. I'll use it a lot more now that I know it's not as likely to reload on me as I thought it was.

Yup. If you run the lines of code at the top of the page I linked to, a window with 2 sliders will appear. It doesn't do anything though. As far as GUIs for scripting languages like Python, Ruby, PHP etc. go, it also loads very quickly (it's a very small library).

You don't save a config file inside a workflow to be distributed. That's kinda the point. Any settings that are user-specific have no place in the workflow itself. Your workflow should have some reasonable defaults. These can be hardcoded in the script or you can include a sample config file that's copied to the default location if no user config file exists. The workflow you linked to includes a workflow library (workflow.php) that provides an API for the workflow to easily set configuration options that workflow.php saves in the proper location. It doesn't include any config files in the workflow itself. Almost all complex workflows use a workflow library that takes care of things like saving settings, caching data and generating XML output for Alfred. It's silly to write all this code yourself. Here's the forum thread with a list of workflow libraries. Alfred's docs can't really provide a proper description of how to write a workflow based on scripts because it supports so many languages. The workflow you're talking about implementing seems to be a relatively complex one. It might be a good idea to read a few tutorials and look at a few other, simpler workflows to get a feel for how they're structured before trying to build something so complex. Here's the tutorial for the workflow library I wrote. I'm told it's very helpful, but it's also very specific to the Alfred-Workflow library and Python. Richard wrote a PHP tutorial here. With regard to compiling a workflow: workflows are basically just zip files. To turn the GitHub workflow you linked to into an .alfredworkflow file, you'd just download the repo, zip it, and then change the extension from .zip to .alfredworkflow.

Any chance you could post more complete screenshots? The current ones don't give much of a clue regarding most of the colours.

There are a couple of de facto directories for each workflow to keep its data in. By convention, settings and so forth go in ~/Library/Application Support/Alfred 2/Workflow Data/com.your.workflow.bundle.id/ and temp files go in ~/Library/Caches/com.runningwithcrayons.Alfred-2/Workflow Data/com.your.workflow.bundle.id/. (Where com.your.workflow.bundle.id is, of course, the actual bundle ID of your workflow.) You don't have to use these specific directories—and Alfred won't create them for you, or enforce their usage in any way—it's just a convention (that almost all workflows follow). There's a bit more information on Shawn's Alfred docs wiki. These data aren't any more secure than in the workflow itself: the main advantage is that updating the workflow won't overwrite your personal settings.

I don't know about other browsers, but Chrome does provide a JSON file containing all of its bookmarks, including folder names etc. So it would be possible to view bookmarks based on the containing folder in Chrome.

Fiddlesticks. If, like me, you don't move around much, you could hardcode your location instead. It's a hack, but it'll get you your damn fine weather forecast for the right place until there's a non-hacky solution. You could change line 49 of forecast.rb from: location = (query.empty?) ? Location.from_ip : Location.new(query) to: location = (query.empty?) ? Location.new("Wien", 48.2, 16.366667) : Location.new(query) Then if you don't specify a location, it will default to Vienna instead of an IP address-based location. AFAIK, you can use "Wien" or "Vienna" or "Home" or "Daheim" or whatever for the first argument. Perhaps @kejadlen can clarify if that's actually okay or if I'm talking nonsense? Also: lol @ "City: Austria"

Scheibenkleister Might be worth getting in touch with the people at Deezer. It doesn't appear to have anything to do with Alfred.

It's strange that all the other outputs work, though. There are a couple of things I can think of that might shed more light on it. This workflow allows you to search the active application's menus in Alfred. You could try that and see what it shows for "Airplay" or "Apple TV". Also, if you have Xcode installed, there's an app called Accessibility Inspector in it (/Applications/Xcode.app/Contents/Applications/Accessibility Inspector.app). Run that app, then hover over the "Apple TV (Airplay)" menu item in Deezer. Check what Accessibility Inspector shows. In particular, accessibilityTitle. It's possible that it's expecting a different name. If that doesn't provide any useful information, I'm afraid I'm all out of ideas…

Try going to http://ipinfo.io/ and see if it tells you the correct location.

That is weird. Does "Apple TV (Airplay)" always work from Script Editor? There's one more thing I can think of. Could you save the script from Script Editor. Save two copies, the first as File Format: Script and the second as File Format: Text. I've no idea what the German equivalent is, but the file extensions should be .scpt and .applescript respectively. Then try running these from Terminal with osascript myscript.scpt and osascript myscript.applescript. My thinking is that AppleScripts behave differently depending on whether they're compiled (.scpt) or not (.applescript).