ctwise

Create a keyword trigger (or hotkey trigger, or whatever you prefer), then create a run script action with 'open focus://focus' in the script box (don't enter the quotes in the box). Oh, and connect the trigger to the run script action.

The intention of Alfred (and other launchers) is to allow you to control your computer from the keyboard. The basic stuff includes: - Stuff like Spotlight (launch applications, open files, enter calculations). - File manipulation (list files in directories, delete files, etc.). - Web searches (Wikipedia, IMDB, Amazon, etc.) - Search contacts - Clipboard history - iTunes player - System command (empty trash, eject disk, quit app, etc.) At it's simplest it's Spotlight+. It's faster for launching apps, it's more configurable, and if you buy the power pack you can take it to the next level. You don't have to know how to program to use workflows. Take a look at http://www.packal.org for workflows that other people have built and shared. Pre-existing workflows let you search various sites and get search results back in the Alfred window, create quick notes or reminders, toggle bluetooth and many other things.

I won't be installing Yosemite until the public release, so I won't be able to check or fix the problem until then.

You can find a version of this workflow on Packal - https://github.com/packal/repository/raw/master/com.tedwise.vpn/vpn_toggle.alfredworkflow I might have used the workflow in this thread as the base, I honestly don't remember.

Alfred Preferences -> Default Results -> Search Scope box -- Add '/opt/homebrew-cask/Caskroom' to the list

The latest version will display keyboard shortcuts. This is _not reliable_ due to the way keyboard shortcuts are handled by some apps. It's why I didn't display them for the longest time. So take them with a grain of salt.

It's probably the version update window that Microsoft insists on showing with every new point release. Run the app normally and click the button that says, 'don't show this update window again'. The workflow should start working again after that. Unfortunately, this workflow will continue to be 'brittle' until Microsoft specifically supports scripting the app.

It's because of line 44 in main.rb: arg = arg.nil? ? "nogui" : arg By default the VMs are started without a window (nogui). It's a "feature". I personally only use VMs to run servers and then access those servers from OS/X. You have a couple of options: 1. Change that line in the workflow to: arg = arg.nil? ? "" : arg 2. Add 'gui' to the end when you start a vm, e.g., 'vm start gui' and then select the vm you want to start.

A new version that fixes the issue has been uploaded to Packal - https://github.com/packal/repository/raw/master/com.tedwise.vmwarecontrol/vmware_control.alfredworkflow

Not sure why that happened. I'm not a VMWare expert. :-) This knowledge base article says you can remove the file and restart VMWare to recreate it - http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2031100 There's also something online about registering VMWare instances to add them to the file, not sure how to go about that though.

The way it's written - no. You can override the priority and date but you can't leave them blank. You'll have to edit the script to do that.

Every application on OS/X uses those symbols. You may not have noticed them, but open any menu on OS/X and you can see the key equivalents use them. Go to Settings -> Keyboard -> Shortcuts and you'll see them again. Use any application that allows you to set keys, same story. This isn't an Alfred thing, it's a OS/X application thing. Here's a link with more symbols used in OS/X: http://tedwise.com/2009/04/28/what-do-those-weird-mac-symbols-mean/ The more power-user applications you use, the more you'll see those symbols.

Ever since Microsoft released a new major version - 8.0 - the RDP workflow has been completely broken. Microsoft, for reasons known only to them, removed the ability to _search_ the defined servers. Since they don't provide an AppleScript dictionary for the app, the only way to script opening a specific server was to use the search function, so the workflow was broken. Microsoft just released 8.0.8 which finally adds the search functionality _back_ into the application. The workflow still didn't work so it needed to be tweaked to the new UI. Everything is back to working normally now for the workflow. You can find it on Packal: http://www.packal.org/workflow/microsoft-remote-desktop Keep in mind that even though this is working the same way it always did before, it's still fragile since it uses UI scripting since there's no exposed scripting support. That means that a new version pop-up window will stop the workflow from working and having focus on a remote desktop instead of the main application will also stop the workflow from working. Until Microsoft adds scripting support, this is the best I can do.

Settings -> Advanced -> Apps Matching -> Full fuzzy match from word boundary Then PS will match Photoshop. Or, you can create a simple workflow that connects the keyword 'PS' to Photoshop and 'LR' to Lightroom.

Alfred doesn't monitor your typing in apps, snippets are only accessible through Alfred. If you want "]keyword" to expand in other apps you need to continue using another product. The benefit to Alfred's approach is getting a list of snippets.

I agree with your basic premise but "pollute" is a strong word. :-) I still pull in everyone I email with at my company into my local address book because I can link them with their LinkedIn profiles using CoBook. Let's me associate pictures with the majority of my contacts and have long-term contact info for them if they leave the company.

I just looked through the programming guide for LaunchBar 6 "actions" which are their equivalent of workflows. Alfred, in general, has more comprehensive workflow support (not even counting the GUI layout tool), but LaunchBar 6 has some features it would be nice to see in Alfred: - Scripts can be marked to be killed if they don't return before the next keypress, e.g., user types 'A', script searches the internet, user types 'B', script is killed and re-run with 'AB' This is an overall feature that's been requested many times but I don't think anyone actually mentioned killing the currently running script. - Scripts support either 'strings' or 'paths' I believe a script that takes a path gets path completion support in the LaunchBar entry box. - Scripts can return a 'string', a 'path' or a complex result LaunchBar assumes defaults for everything if your script just returns a string or a path instead of XML, JSON, etc. - Environment variables are passed to the script w/various paths and information about the state of the option key, command key, etc. - LaunchBar can accept script output in JSON, XML or a property list XML I don't care about property list XML, but I would love if JSON was an option. - Items returned by a script can include a quicklook URL - Items can indicate another script to run to get the next 'level' of items, e.g., a multi-level menu - Items can directly list out the next 'level' of items Various Alfred scripts now have hacks that "re-call" the script and mimic multiple levels of results. LaunchBar bakes it into the workflow model. - LaunchBar actions are code signed - LaunchBar supports using JavaScriptCore as a scripting language - Scripts can marked to be initiated by LaunchBar but LaunchBar immediately returns (doesn't wait for output)

The comparison isn't JavaScriptCore to Node, it's JavaScriptCore to V8. There is at least one implementation of Node.js on top of JavaScriptCore, not sure how usable it is though. I'd very much like to see a benchmark of Node.js on top of Yosemite's JavaScriptCore.

I don't hate AppleScript but I've never been able to completely understand it's syntax. I always have to experiment to fully understand how to use an app's dictionary of functions and properties. JavaScript, on the other hand, is very, very clear, extremely flexible, and thanks to the browser wars, very fast.

I believe it will. I'm not sure if NSAppleScript will run JavaScript. The screenshots of the Script Editor show the user having to select either AppleScript or JavaScript.

Take a look at this link: https://t.co/Y9TDhanIA7 Yosemite supports using JavaScript instead of AppleScript as a scripting language. It's a complete replacement with all of the same features and integrations with Objective-C frameworks. You can run it with osascript, etc. Since I'm posting this in the feature suggestions you can guess what I'm requesting when Alfred is run on Yosemite. :-)

Don't get me wrong, if what we're discussing never gets implemented, I'm fine with that, slightly less happy then if it _does_ get implemented, but still fine. However, it would be awesome if filtering worked _everywhere_ a filename is accepted. Like I said before, if you could provide a globbing pattern, then the base filename could be sent through spotlight and then Alfred itself could filter down the results using the path globbing pattern. So entering 'myproj/**/readme.txt' would send 'readme.txt' through spotlight and then the results would be filtered _by Alfred_ using the 'myproj/**' globbing pattern. You go from hundreds of results to just a handful and it requires very little additional work.

Right, and filtering the results doesn't increase the number of results being returned, it changes which ones are being displayed. So, entering: open python.framework/examples/pyobjc/guitests/readme.txt would be the functional equivalent of this: mdfind name:readme.txt | grep -i python.framework/examples/pyobjc/guitests and far, far more useful then this: open readme.txt In general, where Spotlight is being used as a search source, it would be extremely useful to be able to control that searching more directly using Spotlight syntax, e.g., 'tag:x', 'name:x', etc. in addition to adding filtering.

tell application "Alfred 2" search "whatever you want in the box" end tell

I don't think you're going to get this. It would mean changing "modes" into one that filters the results list by whatever you start typing. For example, you have your list of files, you change into filter "mode" and type text that's in the path of the entry you want, reducing the list down to that file. The approach that's much more "Alfred" is to change the query. Unfortunately, as you've already discovered, the query is literal when it should allow globbing. Following your example, if I type 'open changelog' and get a loooong list of files, I want to narrow it down to one that's below the 'sails' directory, so I _want_ to be able to type something like this 'open **/sails/**/changelog.md' but the best I can get is 'open changelog.md' and then paging through _lots_ of results. So, the feature _I_ would like, is that Alfred searches by the full path unless it contains globbing characters. If it does, search by the file name and filter by the globbing pattern. From the user's perspective it would look like Alfred was searching by a globbing pattern but it would be much more efficient and performant for Alfred.