ctwise

1. Right click the workflow and choose 'Show in Finder'. 2. Double-click on the 'menudump' file. 3. A terminal window should open and it should spit out a bunch of text. It should end in something like this: "menuPath": "Help", "children": [] }, { "name": "Search man Page Index for Selection", "shortcut": "⌃⌥⌘/", "locator": "menu item \"Search man Page Index for Selection\" of menu \"Help\" of menu bar item \"Help\" of menu bar 1", "menuPath": "Help", "children": [] }, ] }, ] } [Process completed] If it doesn't, and it looks like an error message, please post it. If it does look like the above, then the Ruby script might be the problem. 4. To test the Ruby script, you need to open a Terminal and go to the directory it's installed in. That's the directory that Finder is open on. It will be something like: /Users/<youruser>/Library/Application Support/Alfred 2/Alfred.alfredpreferences/workflows/user.workflow.67E62A93-785A-49BA-8B22-EAAEA3FA735A. So type 'cd <the path to the workflow>'. 5. Now run the Ruby script, 'ruby main.rb sh'. You should see text like this: <items><item arg='menu item "Page Up" of menu "View" of menu bar item "View" of menu bar 1' autocomplete='Page Up' uid='Terminal: View > Page Up' valid='yes'><title>Page Up</title><subtitle>Terminal: View</subtitle><icon type='fileicon'>/Applications/Utilities/Terminal.app</icon></item><item arg='menu item "Line Up" of menu "View" of menu bar item "View" of m If you don't, post the result.

You have to walk the whole menu to be able to search it. Dumping is the slow point. On my computer it takes 1.6-1.7 seconds to dump the menu structure for Safari. Contrast that with iTerm, which takes 0.07 seconds. I _could_ special case Safari and exclude History and Bookmarks but then, of course, you can't search them. :-) It doesn't look like it's just a case of menu size either. The Chrome menu dumps in 0.25 seconds. Safari just doesn't like to give up its History and Bookmarks menus. If I exclude those two in Safari the time drops to Chrome territory.

There are lots of issues reported with scripts that fire for each keystroke and new feature options discussed, e.g., delay script firing until the user stops typing for x milliseconds. Here's another option that might work better and be simpler to implement. Provide support for script filters that are only run once. Then Alfred will be responsible for comparing the search text against the script results. For example: item 1: cooking item 2: cleaning item 3: shopping The user triggers the script filter. The script filter returns its complete list of items. The user keeps typing and enters 'c'. Alfred displays only items 1 & 2. The user then enters 'cl' and Alfred displays only item 2. For script filters that need the query to get any results, this wouldn't be an option. For script filters that generate a complete list and then filter the results themselves, it would be. Alfred can also support fuzzy matching this way. The biggest benefit would be performance. If I have a script filter that returns results in milliseconds, it won't matter. But, if I have a script filter that takes a second or two, it will perform much, much better if I only have to fire the script once at the beginning of typing. Obviously, the item title should be searchable but it's an open question whether the sub-title should be as well or whether it should be a checkbox.

It's 10.7+. It uses an API call that didn't exist before 10.7.

The previously released menu search workflow has been universally panned due to the poor performance of the AppleScript that dumps menu contents. The caching of results worked very poorly as a stop-gap. So, I've re-written the menu extraction in Objective-C. It's much faster. The source is here: https://github.com/ctwise/alfred-workflows You can download the workflow directly from http://tedwi.se/u/db To recap, this workflow lets you trigger an application's menu's from Alfred. For example, if you're in iTerm and trigger Alfred, you can type 'm view' to get a list of all menu items with 'view' in the name or that belong to the 'view' menu. Selecting one of the entries triggers the corresponding menu entry in iTerm. In one sense it gives you a command-line to control your applications. The workflow has the beginnings of shortcut key display as well but it's currently disabled due to numerous bugs. Update: v1.3 - Provide error message when assistive devices isn't checked. v1.2 - Skip the Safari History and Bookmarks menus. They take too long. v1.1 - I fixed the bug with Alfred not remembering selections and added AlleyOop support. Download from the same link. Requires OS/X 10.7+. --- You need to turn on OS/X assistive device support to allow this workflow to operate. You can find the checkbox in Settings. The settings page looks very different in recent versions of OS/X but the wording for providing access for assistive devices is very similar no matter what OS/X version you're using. Here's an image of the settings from the latest version of Mountain Lion.

You may find this useful. If you set your terminal application to 'Custom' in Alfred's settings, then you can do something like the below. It runs the shell command in the current terminal without starting up a new terminal window. I use iTerm2, if you're using Terminal.app the AppleScript will be slightly different. on alfred_script(q) tell application "iTerm" activate try -- We don't need error messages set miniaturized of windows to false end try try set _session to current session of current terminal on error set _term to (make new terminal) tell _term launch session "Default" set _session to current session end tell end try tell _session write text q end tell end tell tell application "System Events" set visible of process "iTerm" to true end tell end alfred_script

It's not the speed of the language that's the problem. It's the speed of loading. I just did a quick test on my system for programs that do nothing else but print "hello": ruby - 0.01s python - 0.01s php - 0.03s groovy - 0.81s Those times are consistent. A Groovy script takes almost a whole second _just to start_. Once it's running? Yes, it's as fast or faster then the others. But most of the scripts fired off by Alfred are short and run for far, far less then one second. You want a server that runs for a while? Groovy's a good choice. You want a command-line processing script that should finish in under a second - not so much.

Groovy start-up is too slow for fast-firing scripts. Groovy's fine for web applications (I develop mainly in Grails myself), but PHP, Python and Ruby are much better choices for small, short-execution scripts.

You'll find another version here - it takes a different approach and provides task entry as well. - https://github.com/ctwise/alfred-workflows

Not sure about Parallels, but you can do it with VMWare, e.g., 'vmrun -T ws -gu guestUser -gp guestPassword runProgramInGuest "c:\my VMs\myVM.vmx" "c:\Program Files\myProgram.exe"' You have to authenticate to the guest OS to do it. Annoyingly, the same is true of taking screenshots.

Multiple chipsets look like this: Graphics/Displays: Intel HD Graphics 4000: Chipset Model: Intel HD Graphics 4000 Type: GPU Bus: Built-In VRAM (Total): 512 MB Vendor: Intel (0x8086) Device ID: 0x0166 Revision ID: 0x0009 gMux Version: 3.2.19 [3.2.8] NVIDIA GeForce GT 650M: Chipset Model: NVIDIA GeForce GT 650M Type: GPU Bus: PCIe PCIe Lane Width: x8 VRAM (Total): 1024 MB Vendor: NVIDIA (0x10de) Device ID: 0x0fd5 Revision ID: 0x00a2 ROM Revision: 3688 gMux Version: 3.2.19 [3.2.8] Displays: Color LCD: Display Type: LCD Resolution: 2880 X 1800 Retina: Yes Pixel Depth: 32-Bit Color (ARGB8888) Main Display: Yes Mirror: Off Online: Yes Built-In: Yes Connection Type: DisplayPort

Nice work. It doesn't support multiple graphics chipsets though.

Or you can just create a workflow. Setup three keywords (that take no argument) and attach each to a unique action to Launch Apps. Drag the application you want to launch into each Launch Apps action. Problem solved.

Sparks - keyboard app launcher I still use Soulver as a calculator - it supports multiple lines, units, etc.

That particular example is 'find .caf'. 'find' searches filenames, 'in' searches file contents. I don't believe there's any way to do complex Spotlight queries without writing a workflow.

Some of it. DTerm uses the Accessibility API and Scripting Bridge to determine the path for the front-most app. You'd have to rip the code from DTerm (https://github.com/bdrister/dterm) that gets that front-most path or selected files in Finder/PathFinder and create an executable that spits out the path(s). Wire up an Alfred hotkey to that code and do what you like with the results.

Nice. You might want to change to xargs to support spaces. So, your perl becomes this: echo "{query}" | perl -pe 's/[\t\n]/\0/g' > file_list And your bash becomes this: cat file_list | xargs -0 {query}

try cd ~;open /Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs --args -l /Users/gnn/.emacs-login

Dev Doctor - Syd Lawrence - http://www.alfredforum.com/topic/1420-dev-doctor-documentation-autosuggest-search/

http://www.alfredforum.com/topic/1146-pathfinder-support-is-not-working-as-intended/?hl=pathfinder

I'm not much for great job posts, but really, great job!

Just let AppleScript ask for the password. If you just use 'with administrator privileges' it should work fine.

Very, very nice workflow. If you change the hotkey to 'Selection in OS/X', it will auto-copy the selected text to the clipboard for you. Then you can connect the hotkey to a one-line bash script that does this: osascript -e 'tell application "Alfred 2" to search "| "' Then the hotkey copies the selected text and triggers the workflow in one step. You can also take the 'pbcopy' out of the zsh script and put the 'Copy to Clipboard' step at the end. Then you can check the box 'Automatically paste to front most app'. Now, when you select text, trigger the hotkey and select a filter, the result will replace the selected text. In addition, the list of items is clearer (at least to me) when the description is the title and the command-line is the subtitle. So, with a few formatting changes, it looks like this: title: Encode base64 (builtin) subtitle: openssl base64 -e

Never mind, turns out the selection works by copying to the clipboard anyway. I never even tried it first. You can even see it happen because the Edit menu flashes.

The Objective-C handler for running shells is aggressive in reaping children. I haven't found a reliable mechanism for kicking out sub-shells that Alfred will ignore. If your data source is super slow AND is query-specific, you're best keying off of something, e.g., tacking on a period at the end of the query and waiting to see the trailing period. If your data source is super slow and ISN'T query-specific, check for the cache at the top of the script, use the cache if you find it, generate it if you don't. It'll be slow the first time and fast the rest of the time.