ClintonStrong

Just so I can figure out if it's a problem with the AppleScript part of the workflow, could you open up AppleScript Editor, create a new document and see if this code runs? (You'll need to have Chrome open.) on run argv set theOutput to "" set windowIndex to 1 tell application "Google Chrome" repeat with theWindow in windows try set tabIndex to 1 repeat with theTab in tabs of theWindow set theOutput to ((theOutput & windowIndex as string) & ":" & tabIndex as string) & " " & URL of theTab & " " & title of theTab & " " set tabIndex to tabIndex + 1 end repeat end try set windowIndex to windowIndex + 1 end repeat end tell theOutput end run You should see something like this in the output if it's working properly: "1:1 https://www.google.com/ Google 1:2 http://www.alfredforum.com/forum/3-share-your-workflows/ Share your Workflows - Alfred App Community Forum 1:3 Search Safari and Chrome Tabs - Share your Workflows - Alfred App Community Forum " Also, does it get stuck on "Retrieving tabs...", or does it eventually show your fallback results? And what version of OS X are you running?

Sorry about that. Try double clicking the script filter in Alfred Preferences and set the script to this: /usr/bin/ruby search_tabs.rb "{query}" 2> ~/Desktop/errorlog.txt Try typing 'tabs' into Alfred again, then check your Desktop for an errorlog.txt file. Let me know if any error messages were logged there.

I suppose there is another option: you could just force your workflow to run on Ruby 1.8.7. Mavericks comes with both 1.8.7 and 2.0.0 installed, you just have to point it to the full path for 1.8.7. /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby That should work with older installs of OS X as well. Just throwing that out there.

Ah yeah, that download doesn't seem to have the Ruby 2.0.0 versions of the gems bundled with it. When I cloned the repository into Alfred it worked fine.

It looks like it's an encoding issue. When I ran your workflow in Alfred, it output this error message: plist-3.1.0/lib/plist/parser.rb:91:in `scan': invalid byte sequence in US-ASCII (ArgumentError) from plist-3.1.0/lib/plist/parser.rb:91:in `parse' from plist-3.1.0/lib/plist/parser.rb:29:in `parse_xml' from alfred-workflow-1.11.1/lib/alfred.rb:122:in `info_plist' from alfred-workflow-1.11.1/lib/alfred.rb:127:in `bundle_id' from alfred-workflow-1.11.1/lib/alfred.rb:100:in `ui' from alfred-workflow-1.11.1/lib/alfred.rb:47:in `rescue in with_friendly_error' from alfred-workflow-1.11.1/lib/alfred.rb:28:in `with_friendly_error' from ./search.rb:62:in `<main>' I did some further testing and it looks like the external encoding of Ruby is set to US-ASCII when run in Alfred, while it's normally set to UTF-8 when a script is run elsewhere. Looks like this is why it works in the Terminal but errors out in Alfred. You can manually set the external encoding to UTF-8 by adding the following line of code at the top of your Ruby file: Encoding::default_external = Encoding::UTF_8 if defined? Encoding That seems to fix the issues on my system anyway. Hope that helps.

Added support for Mavericks. If anyone runs in to any problems, let me know and I'll try to get it fixed.

Yep. Let me know if you have any problems.

Mavericks ships with an updated version of Ruby, which has some compatibility issues with older versions. The main issues are with the load path (you have to either manually add the workflow directory to the load path or explicitly use the full path of a file to load it), and with character encoding. If you want a quick fix, you could probably get some of the workflows to run in 1.8.7, the version Mountain Lion was using. It's located at "/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/". If you need any help with that, just send me a message.

Sorry about that. Should be fixed now: Download

Nice, thanks for the workflow. I'll look in to maybe adding a config file for adding custom shortcuts. I like the idea!

This is an issue with the workflows, not with Alfred. Mavericks comes with an updated version of Ruby (v2.0.0), which has some compatibility issues with code written for v1.8.7 (the version of Ruby included with prior releases of OS X). It's likely there's an issue with encoding in those workflows, particularly if they're getting data from somewhere else (a file, an HTTP request, etc.). I made some hacky attempts to fix the Recent Downloads workflow (check the last few posts in the thread), but I still need to do some more testing there.

Sure, feel free to post it here. I've been thinking about how to make the workflow more flexible, especially with finding pages that aren't already open. I was thinking about having it fall back to a history search if you add a character to the end (maybe an exclamation mark). So you could type "cal" to search for Google Calendar, and if it's not open, you can type "cal!" to search it in your browser history. But I do like your idea. I'm interested to see how you implemented it. I'll work on refactoring the code and then play around with adding new features. This was the first Ruby code I ever hacked together, so it could use some work.

I think I got it fixed: Recent Downloads If it works for you without any problems, I'll go ahead and submit a pull request so ddjfreedom can update the workflow with the fixes. (The problem was the way Ruby handles string encoding in 2.0 vs 1.8.7. Had to explicitly set the string encoding to UTF-8 to get it working properly.)

All right, think I got it fixed this time. There was an issue with string encoding (which is why those Spanish language websites were causing problems), but I've just updated the workflow and it seems to be working now. Let me know if you encounter any other issues.

I tried resolving the file paths to absolute paths. Let me know if that fixes it for you: Recent Downloads

What kind of error are you getting? You can go into Alfred Preferences and right click the workflow in the sidebar, then select Show in Finder. Open up the Terminal app, and drag and drop the workflow's folder into Terminal. Then copy and paste this command and press return: /usr/bin/ruby recent_downloads.rb " " Let me know if you get an error after running that. I don't have access to Mavericks right now, so unfortunately I can't test it myself.

D'oh, was meaning to check if it would work with Ruby 2.0.0. Thanks for the heads up. I updated the original post with a new download that should hopefully fix that. Hmm, interesting. Tested it out and it is indeed acting strange (only tested it on Mountain Lion so far). Thanks for letting me know about it. I went ahead and implemented your fix for the first scenario. Also fixed some issues where the workflow occasionally wouldn't focus the correct window. Still not sure what to do about the other two scenarios, but I'll keep playing around with it.

Alfred does matching anchored to capital letters, so "dl" matches the the the "DL" in the IDLE app. Workflow results are mixed in with Alfred's default results, so you'd see IDLE.app in the results regardless of whether or not you have the workflow installed. You could try changing the keyword to something that doesn't bring up any other results (may not be optimal), or you could add IDLE.app to Spotlight privacy to hide it altogether, but of course that's only a viable solution if you never intend to launch the app. One workaround could be to add IDLE.app to Spotlight privacy and make a workflow with a keyword of "idle" to launch that app. It'll show up when you type "id" or "idl", but not when you type "dl".

It uses the previews Safari generates, which usually end up getting squished by Alfred — they match the aspect ratio of your browser window, which usually won't fit into the square icons Alfred uses. I still think it's a good trade off as it makes it easier to find the tab you're looking for, but I do think it should be optional. I'll work on setting up a config file for this.

Thanks for pointing that out. Just published a new version (link in the original post), so let me know if you have any problems. Oh, and I threw in webpage thumbnails for Safari users. It doesn't seem to work with pages served over SSL (HTTPS), but I tried to add in some placeholder images to help with that. It's still an experimental feature, so let me know if you have any feedback.

I had this issue a while ago, but it resolved itself when I updated to the latest version. Not sure what might've changed to fix that, or if it was just a coincidence. Just to be sure, are you running the latest version?

You could always use the file buffer. Press shift+up to add a file to the buffer, then press shift+right and type "delete" after you've added all the files.

I added this to my QuickCalc workflow, if you want to take a look. Unfortunately, there isn't any way to replace the built-in calculator, but you can set up a hotkey or change the default keyword to make it a bit easier to access. Oh, and you don't have to worry about variables and custom functions if you don't want to. You can just use it as a basic calculator. I'm thinking about adding an option to have numbers with spaces in between automatically added together, to make things a bit easier for people without a numpad. I can't really use '=' for addition since Alfred already uses it for calculating an expression. (Edit: I actually could use '=' as an alias for '+', it only has problems if you reassign the keyword to '='. I'll think about adding this.)

I have this issue too. I think it might be related to the result padding. If I duplicate the default theme (Light), and increase the result padding by 1, it shows the upside down icons in the file buffer (I've only seen it happen with applications and folders). If I change the result padding to anything else, the icons are fine.

When I do a file search and action a folder (opening it in Finder), Alfred learns and moves it closer to the top of the results. However, if I navigate into that folder (by pressing command+down) within Alfred, it doesn't seem to learn. I usually just use Alfred's file navigator rather than opening folders in Finder, so it's a bit counter-intuitive to have to open it in Finder first for it to be placed near the top of the results. It'd be nice if Alfred could learn when you navigate into a folder.