Recommended Posts

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

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.

Share this post

Link to post

I kind of use the same menu items in some applications and sometimes I don’t remember the hotkey or I don’t want to set up a hotkey. Now this leads to my suggestion: add favorites/history menu items per application. For example: I’m in Byword and instead of search for the menu item I would bring Alfred and type mf or mh and get a list of favorites or last used menu items for Byword.

Share this post

Link to post

thanks for this, it is indeed a lot faster and very useful! there is one thing that was mentioned before that still does not work. some menu items are dynamic and change depending on the "mode" of the application. for example in lightroom, depending on which module i am in, the items in the View menu change and some do not show up in Alfred. Would you possibly have some time to investigate if there is way to make these show up? thank you.

Share this post

Link to post

Maybe the workflow could display results in steps, like 20 results. In addition, if I type something and get 100 items it will hard to browse all those items in Alfred anyway.

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.

Share this post

Link to post

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.

Considering there are already other workflows to search Safari's history, it may not be a bad idea to exclude them.

Another idea is to do the searching in Objective-C, and limit the results from there. Not sure how feasible that would be though, or how much that would actually affect performance.

Share this post

Link to post

Good job keeping the workflow alive. I modified my original post to point to this new topic, hopefully that will help people find this newer version.

Is the source code to your menudump executable as well on your github? I would prefer for things to work without any form of cache, which could possibly be achieved by limiting the recursion depth of the menus (assuming that you are recursing). That would probably also allow handling (probably hiding) of disabled menu items. Disabling caching would also make toggle menu items (such as Safari's "Show Web Inspector"/"Hide Web Inspector") work properly.

The goal would be to get the entire workflow to execute in less than 200 milliseconds. 100ms would be better, as it has that instant feel to it, but 200ms would still feel semi-instant.

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: