ctwise

it's really a good one

 

I've found a strange behavior. if you type "pubmed rochebro" you wait and it gives you the articles linked to the authors. this if fine.

 

But you add more letters to finish the author name (the complete name is rochebrochard) and / or delete some, at some point you have the search google /  amazon / wikipedia for "pubmed xxx"

 

It looks like a bug, bug I'm not sure if it's Alfred's or not.

It's a bug in the workflow, due to UTF-8 encoding. Fixed and a new version was uploaded.

Sure:  https://dl.dropbox.com/u/10028577/vmInventory

Defect fixed. Updated at link and on alfpt.

Alfred always waits for a single script filter object to finish before calling it again, so if it calls on the first character you press and takes a few seconds to reply, it will only get called again with the current query at this point (e.g. if you have typed 6 further characters, the script gets called with these 6 characters, not all the separate times inbetween).

That's good to know but if a script takes five seconds to return results and I type the query 'avengers', then I get script results for 'a' and ten seconds later I get script results for 'avengers' as opposed to five and a half seconds later for a timeout of 500 milliseconds.

Script filters fire for every key press. That is fine for lightweight script filters that can respond quickly but is a problem for heavy script filters that take significant time to operate. It would be helpful to support script filter throttling. This might be as simple as a checkbox ("Throttle requests"). It would work by waiting a short time between key presses, if another key is pressed the timer resets, if the timer expires the script filter is run.

It's possible to emulate this in a script but it's such a common use case it would be helpful to have it in Alfred.

Errors would be nice to get. :-) But until that happens you need to pare down your results to get to the smallest example that works and binary search your way to the problem.

Great workflow!  

 

Minor issue - I get repeat actionable items - not sure where they are coming from.  See photo in link:  http://db.tt/yqVyMltZ

 

Thanks!

Can you post this file? ~/Library/Application Support/VMware Fusion/vmInventory

If that doesn't exist, then this file: /Library/Application Support/VMware/VMware Fusion/Shared/vmInventory

The workflow has been updated, both at the above link and on alfpt. I added the following:

vm list - now copies the vmx path to the clipboard

vm ip - list the ip addresses of all running vms and copies the selected ip to the clipboard. The vm _must_ be running vmware tools for this to work.

vm revert <name> - revert a vm to the named snapshot.

This intrigued me so I came at it in two different ways. One script filter looks up the term being entered and provides a list of articles with titles, dates and authors. Choosing one of the entries takes you directly to the summary page.

The other script filter does an autocomplete for search terms, e.g., 'diabetes' gives you options like 'diabetes mellitus'. Choosing one of the entries takes you to a search page for that search query.

Pick your poison.

I created a workflow inspired by the Parallels controller workflow. It doesn't do screen captures since VMWare requires a username / password to do that, otherwise it's pretty similar. It's on alfpt or you can download it from here: http://tedwi.se/u/d4

The following commands are available:

It would be very helpful to be able to copy both complete workflows as a basis for a new workflow and to copy specific workflow modules.

Awesome news on the type="file"! Thanks!

Why not just specify path to the executable? Also, are you sure that PATH isn't available? I can easily get values for HOME and other variables from bash scripts.

In this specific example the idea would be to offer suggestions, e.g., 'run mount' would give you the '/sbin/mount' command, but 'run <some script in some other bin directory>' would give me that option. If I dump the PATH from a script in Alfred it's not the full path set by .bashrc, indicating it's not running a login shell (which it shouldn't by default).

One input and one output for each module in a workflow makes it easy to understand and use.

Also it is possible to connect multiple triggers and script modules to one script module so the modules cannot have a "knowledge" of the pipeline they are in.

 

And as phyllisstein David said, you can always nest your queries with a delimiter and pass them on to the next module...

If I embed the information in the value returned by an earlier stage that couples later stages _more_ tightly, not less.

You could use a File Action instead of File Filter and then use it like this:

 

'~/Desktop/a_file.txt upload'

 

(Use file navigation to find the file and then use your File Action)

Yep, and I do this already. If I'm focused on the file that works fine, but if I'm focused on the action I can't do it the opposite way.

The file filter uses Spotlight for searching for the file filter query. It would be nice to be able to enter paths and get completion support, e.g.:

'upload <some filename I hope was indexed by Spotlight'

vs.

'upload ~/Desktop/<get completion support for files and directories in ~/Desktop'

It would be nice to be able to generate a list of context items for results of script filters.

The bash scripts aren't executed in a login session so they don't have access to the environment setup in the bash scripts. So, if I want to implement a 'run' workflow that allows me to execute any command-line application, I can't make use of 'compgen -c' in a bash script because it doesn't have access to the user's path, just the default path.

"If you're not calling a script from the command line, you could just split a given {query} by spaces..."

Yes I could. But instead of injecting it into every step in the workflow, it would be easier and cleaner to provide the original query. Hence my request. :-)

The Google Search workflow is awesome but has one small issue - if there are no search suggestions it ends up searching google for 'g {query}' instead of just '{query}'. It can be remedied with one small change to the script filter, adding an item to the suggestion list if no suggestions were found, e.g.:

The problem isn't in a single script, it's between workflow components. For example, if I have a script filter followed by a script to handle the result of the script filter and want a notification at the end along the lines of 'Uploaded file {original-query} to {query}'. I can't do it. I can get halfway there by returning the whole notification line as the value of the script _after_ the script filter, but even then I've already lost the original query and have to go through gyrations in the script filter to compensate.

People are creating helper API scripts to bundle with workflows. It would be helpful if they were consistent for all languages, and, best of all, always accessible without being bundled into each workflow.

When creating a pipeline of actions you lose the original value of {query} in later stages. This is correct but it would be useful to have access to the original query, e.g., {original-query}, regardless of what changes have been made in the pipeline.

This is a workflow to support killing a process (as opposed to quitting an app). It uses the new infrastructure to list the processes that match a given name, e.g., 'kill java' will list all of the processes that include 'java' in their names. Holding down 'alt' will do a 'kill -9' instead of a regular kill.