ctwise

Embarrassed to say, but it doesn't work on my machine. Result is always loading, for all apps I have tried (safari, terminal, finder). I have osx 10.8.3.

 

Not sure how to debug the workflow, wish I could provide more info.

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.

History in Safari may slow down indeed.

 

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.

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.

Sounds terrific but for some reason it didn't work for me.  It just got stuck saying it was loading.  I'm on 10.6.8 - maybe the workflow only works for 10.7+?  Maybe it's just me?

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 has a negligible extra, but not in those figures I could not sleep overnight . 

http://keyzero.wordpress.com/2010/05/26/groovy-vs-ruby-vs-python-performance/

 

Just that support would be nice as there is a large groovy community. I understand the issues mentioned by David, but still I think this could be solved for example by not allowing to import workflows for which a environment is not present on the system. I' m not the alfred guru, so just asking. 

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.

Would it be possible to add support for groovy based scripts.

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

Quick question about Parallels... has anyone been able to get Alfred to cross into the guest OS?  I would love to be able to perform actions in my virtual machine through Alfred...

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:

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

OK, I'll see if I can figure out a good way to do this (or change my habits)

 

As for 'gj' and 'gjo', they are site specific browsers (each using it's own set of login info etc) but I'll figure out some way of handling this.

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.

I still haven't figured out how to do Spotlight-like searches, for example:

 

filename:.caf (only files with caf extension)

 

I know how to do this, but only with filters, etc. How to do it directly in the Alfred prompt?

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.

DTerm is useful and nice enough that it probably doesn't exactly need replacing. But as since finding Alfred I've been able to ditch so many other little utilities, I'm just wondering if it would be feasible to write a workflow that would do DTerm's job. I'm a developer, but have a genetically-predisposed horror of AppleScript, so don't offhand know if this is feasible. Would be interested in opinions.

 

DTerm is a great little app that allows you to run shell commands from its own mini-terminal, but the magic is that it sets its working directory to wherever the frontmost app window's open document is located. Which is great -- you can, for example, be in an editor/IDE, pop up DTerm (with a keyboard shortcut) and run git commands from the directory of the file you're currently editing.

 

It can also optionally run a command in a real Terminal (or iTerm) window if desired.

 

Could this functionality be replicated in an Alfred 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.

This is a file action to run a terminal command on selected files/directories.

 

Just use Alfred to pick what you want to run a command on and pick “RunCommand”, as the action. Alfred’s main window will appear and you simply type the command you want.

 

Extra notes

The workflow actually consists of two parts. The first one is the only one you’ll want to call explicitly; “RunCommand”, which calls “runcommand”. I’d prefer to have done this a bit differently, but Alfred doesn’t allow connections to the “File Action” trigger that’d allow to do it (at least not without adding a lot more).

 

Download

https://github.com/vitorgalvao/alfred-workflows/raw/master/bin/RunCommand.alfredworkflow

 

Source

https://github.com/vitorgalvao/alfred-workflows/tree/master/RunCommand

 

License

I don’t care, do whatever you want with this. If you make any changes that could benefit the script, I’d certainly appreciate if you’d share them (perhaps I could incorporate them), but it’s not at all required.

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}

Hi,

 

This worked under Alfred v1, but then there were no workflows there.  I have a work flow where I type "emacs" and that launches emacs with some arguments.  If I do this as a bash script, even if I append & (ampersand, the backgrounding command) to the end of the line, then I can't run the script again until I exit the first emacs.  I can make this work by using a Terminal.app action instead of a script, but that's annoying as the terminal briefly flashes on my screen.

 

This is my current command and the one that I tried with bash, but which only works in Terminal:

 

 

 

cd ~;/Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs -l /Users/gnn/.emacs-login &; exit;
 

Thanks,

George

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

Hey guys, I've just created "Dev Doctor" it has autosuggestions for development amongst others

 

http://wemakeawesomesh.it/alfred-dev-doctor/

 

 

A simple walkthorugh of the kinds of things you can do with Alfred Dev Doctor.

A really simple documentation helper for alfred.

Supports:

Languages & Frameworks with autosuggest search

PHP - php {query}

JavaScript - js {query}

jQuery - jq {query}, jquery {query}

HTML - html {query}

CSS - css {query}

Python - py {query}, python {query}

node.js - node {query}

Ruby on Rails - rails {query}

Haskell - haskell {query}

Erlang - erlang {query}

C - c {query}

Languages & frameworks with keyword search:

Laravel - larval {query}

Bootstrap - bs {query}

Flask - flash {query}

.NET - .net {query}

Java - java {query}

Android - android {query}

iOS - ios {query}

Asset search

github repos - github {query}

icons - icon {query}

 

Let me know what you think of it

 

It's also on github https://github.com/sydlawrence/alfred-dev-doctor

 

Syd

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

tell application "System Events"
	set theText to name of current user
end tell
display dialog theText default answer "" with hidden answer
set the adminpass to the text returned of the result

tell application "Finder"
	set iconPath to (get name of startup disk) & ":Applications:Utilities:Boot Camp Assistant.app:Contents:Resources:DA.icns" as alias
end tell

do shell script "bless -mount /Volumes/BOOTCAMP/ -legacy -setBoot -nextonly; shutdown -r now" password adminpass with administrator privileges

I have this applescript that restarts into windows and prompts for admin password before it does so. I can't figure out why it works in the applescript editor perfectly fine, but when run through alfred it doesnt prompt for the password or run at all....thoughts?

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

Added a Hotkey object to the start of the workflow: once defined, you can save a few keystrokes. Copy the text you want to process, hit your hotkey, enter your one-liner and paste the results.

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

This may lead to the same issue you mention above and probably isn't favored but have you tried to do something like grab the data and save it to the clipboard using a simple applescript?

tell application "System Events" to keystroke "c" using command down
tell application "System Events" to return (the clipboard as text)

 

I used that.. Stuck a keyword in front of it and large type after, and that would grab selected text and show it in large type.

 

Or.. this seems to work for me...

echo "{query}" | pbcopy
pbpaste

 

Especially after telling it to escape double quotes. Would that not work?

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.

Hi, 

 

my workflow shows results from a large database and caches the relevant information from this database so that the information is easier and faster to retrieve (I have a search index and separate files for each database entry). The problem is that I don't know when to run the caching function. It slows everything down. Here is what I tried: 

 

1) run it in the background using subprocess or from the shell (still seems to stop alfred from showing my results)

2) run it after printing the feedback (Alfred seems to wait until the end of the script before showing any results

3) run it when len(query) == 0 and only show results when len(query) > 2. I thought that is a good idea but now I would like to show the results from the last search before the user has entered at least three characters.

 

And ideas?

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.