stuartcryan

Search, activate, reload and close your active Chrome and Safari tabs and favourite sites.
 
RBT allows you to do the following all from within Alfred:
Search all open tabs across Chrome and Safari and load a selected tab. Reload a tab forcibly when you select it if you want. Add "favourite" sites to the workflow for quick access with defined keywords.  Synchronise your favourites across computers.    
RBT for Alfred has been forked from the Search Tabs on Safari and Chrome workflow developed by Clinton Strong (with Clinton's blessing) and could almost be considered v2 of Clinton's original workflow.
 

 
The below instructions are a clone of what is posted on the official Github repository:
 

UPDATE August 8, 2015 - Version 1.1 Released
Today I release v1.1 of Rapid Browser Tabs which has the following changes:
Fix - Tab icon for Safari did not display Feature - Add "ctrl" key modifier to force reload tab on opening Feature - Provide feedback on settings initialisation and sync Feature - Enable favourite searching by URL
Installation
Download the .alfredworkflow file or you can get it from Packal. Run to import into Alfred Setup
Before you can do anything with the workflow you will need to initialise the settings:
Run rbtsetup and select 'Initialise Workflow Configuration' The workflow will then copy over the default configuration files and example icons.
 
 
The workflow has been designed to enable settings synchronisation via a mechanism of your choice (such as Dropbox). It is easiest to set this up before you get too deep into configuring the workflow.
To configure synchronisation via Dropbox (as an example):
Run 'rbtsetup' and select "Set root config folder location" Update the folder name to point to a new location, my personal preference is "~/Dropbox/AlfredSync/Workflow Data/com.stuartryan.alfred.rapidbrowsertabs/" (however you can use any location as long as you set it to be the same on different computers) Ensure you have ended your path with a trailing forward slash (things will break if you don't) and then save and close the configuration file. If this is the first computer you are setting the workflow up on (i.e. that directory does not exist or is empty) run rbtsetup then select "Refresh workflow configuration" to copy the default configurations into place Repeat steps 1 to 3 for every subsequent computer you will run the workflow on (after the initial sync has completed via Dropbox).
 
 
Configure a hotkey: To make your life easier I also recommend you set up a hotkey for use with the workflow.
Open Alfred Click Workflows --> Rapid Browser Tabs Double click on the Hotkey box Enter your hotkey and ensure the action is set to "Pass through to workflow" The argument should be set to "None" Click Save Basic Usage
The default keyword set is "rbt" here are some examples of what you can do:
rbt google - Will show all tabs you currently have open that have google in the URL or the tab description. rbt fb - FB is set as a keyword for Facebook. This will show any current Facebook tabs already open and will also allow you to open a new Facebook tab in your default browser as well. rbt nf - Same thing as above but will open Netflix rbt netflix - Same as above, workflow will recognise this is a favourite site and show all tabs currently open and will also offer the option to open a new tab to the Netflix website. ctrl key modifier - The control key when held down while selecting a tab will force the tab to reload/refresh when it is opened For backwards compatibility with the human brain (and the fact that everyone is used to using the keyword "tabs"), an additional entry point into the workflow using the keyword "tabs" has been added. Depending on user feedback this may be removed or adopted permanently in the future.
 

 

 
 
Advanced Configuration - Adding your own favourites YAML Config File
Once you have the hang of the basic usage of the workflow, you can get down to configuring extra "Favourites".
The favourites have been designed to represent the most used sites you use, the ones that you access day in and day out so that you can get rapid access to them.
I have found after setting these up originally I have only added to the list a couple of times as it is expected the list will become relatively static after the first couple of weeks usage.
To access the sites configuration:
Run rbtsetup then select "Modify Sites Configuration" The default configuration example has examples that you can copy and modify to add your own favourites The two basic styles of configuration are:
First Example:
YouTube: aliases: "-yt" icon: youtube.png url: "https://www.youtube.com" Second Example:
? "YouTube Video Manager" : aliases: "-yta -ytvm -youtube admin" icon: youtubeadmin.png url: "https://www.youtube.com/my_videos" The key difference between the two above examples are the use of the '? "Site name"' in the second example. When the site name has spaces, you should copy the second example. You can however always opt to use this format regardless of whether the site name has spaces or not if you want to go the easy route.
The aliases section can list zero or more aliases (for zero just use "", and do not delete the line). Each alias should be prefixed by a dash '-', and you can have as many keywords as you would like (but remember... less is more).
If you are having problems with the site configuration you have created, a great first point is to run it through YAML Lint which can validate if there is anything invalid in your syntax. If that comes back clean and you still have issues please log an issue.
 
 
Adding the pretty favourite images
You will notice in the above example each item references a png icon file. You can save icons that you would like to represent your favourites in the icons folder. This is accessed by typing 'rbtsetup' then selecting "Open icons storage folder". As long as the icons in this folder match what you put on your text you can use a pretty icon.
If you would rather not use an image just use 'icon.png' and this will use the default icon for the workflow.
 
Supported Browsers
Currently the workflow supports the following browsers. As Firefox does not expose its tabs via Applescript, it is not able to be supported. If someone is a whizz at writing Firefox plugins and would like to collaborate on a plugin to get this to work please feel free to get into contact with me.
Chrome Safari Chromium Chrome Canary Webkit History
Version 1.1 - Bugfix and feature releaseFix - Tab icon for Safari did not display Feature - Add "ctrl" key modified to force reload tab on opening Feature - Provide feedback on settings initialisation and sync Feature - Enable favourite searching by URL Version 1.0 - Initial Release of Rapid Browser Tabs for Alfred Version 0.9 - Forked from Search Safari and Chrome Tabs workflow Feb 2014 release Credits
Rapid Browser Tabs for Alfred workflow created by Stuart Ryan. If you would like to get into contact you can do so via:
@StuartCRyan on Twitter Stuart Ryan on LinkedIn Technical Notebook Blog Search Tabs on Safari and Chrome workflow created by Clinton Strong represented the initial stages for this workflow.
Clinton has been kind enough to provide his blessing for the code to be forked and maintained as a new workflow. Any future code releases to the Search Tabs on Safari and Chrome workflow may be merged into this workflow if required (and as long as the original licensing permits). License
All code in this workflow is released under the MIT License. Images used as part of the workflow are licensed only for use in this workflow and must be changed if the workflow is forked in the future.
All images have been licensed from DepositPhotos to Stuart Ryan.
 
Donations
This workflow represents many many hours effort of development, testing and rework. The images licensed for this workflow from DepositPhotos also needed a bit of my moolah. So if you love the workflow, and get use out of it every day, if you would like to donate as a thank you to buy me more caffeine giving Diet Coke, some Cake, or to put towards a shiny new gadget you can donate to me via Paypal.
 

 
Contributing
If you are a coder head over to the official Github repo:
Fork it! Create your feature branch: git checkout -b my-new-feature Commit your changes: git commit -am 'Add some feature' Push to the branch: git push origin my-new-feature Submit a pull request If you aren't a coder:
You can drop your ideas here or feel free to log your ideas and suggestions on GitHub and I will see what I can do.

Custom Terminal AppleScripts to Integrate iTerm and Alfred
 
iTerm version 3 beta:
The iTerm 3 beta version is the same version we have had for quite some time, which is also known as 2.9. Therefore the v2.9 branch of the script will work just fine with the v3 (aka 2.9) beta and v3 when it is released (any major changes to iTerm's applescript not withstanding).
 
In a blog post released recently (19th August 2015) Vero (Alfred's Mum   ) has announced that as of the next version of Alfred, these custom terminal scripts will be the available mechanism for integrating Alfred and iTerm:
 
"With the upcoming release of Alfred 2.7.2, the default iTerm integration has been replaced by the "Custom" scripts option. This allows for a more up-to-date and more flexible way to handle the iTerm integration, using scripts created by one of our fantastic users, Stuart Ryan."
 
I would like to thank Vítor for helping to clean up the applescripts and submitting some great pull requests .
 
There are two versions of the script available:
iTerm 2 Branch (tested up to 2.1.1) - view the v2.1 script on Github - updated December 14, 2015 iTerm 2.9 Branch (tested up to 2.9.20150626) - view the v2.9 script on Github - Updated December 14, 2015 Each of these can be inserted into Alfred by following these steps:
Load the Alfred control panel Click the Features Button/Tab Click on the "Terminal/Shell" menu on the left hand side Select "Custom" under application, and replace the text in the new box that appears with the code as per the version of iTerm you are running. Alternatively, check out the official YouTube video on how to set them up:

 
iTerm 2.1 Branch Custom Terminal Script Features:
The 2.1 branch script is very basic and just corrects the opening of iTerm and creating a new session properly.
 
Change Log:
V0.4 Release - Vítor's submitted pull request for simplifying the check for if iTerm is already running. - December 14, 2015 (apologies for the delay in merging) V0.3 Release - Added version number and Vítor has done some great work standardising the scripts. No functionality changes in this release - August 14, 2015  Remove Trailing Whitespace (Vítor Galvão) - August 10, 2015 Initial Release - July 31, 2015  
 
iTerm 2.9 Branch Custom Terminal Script Features:
 
The 2.9 Branch goes a bit further to utilise some of the new features of iTerm 2.9 (which is in beta at the moment and can be downloaded if you are feeling adventurous from the iTerm download page). The script has been designed to achieve the following:
Open the correct iTerm binary under /Applications/iTerm.app regardless of if another iterm/iTerm binary exists on the system Always create a new tab/session, unless iTerm is not running, in which case use the default session. If the user has selected to not create a default session on iTerm startup, detect and create a default session. Change Log
V0.6 Release - Vítor's submitted pull request for simplifying the check for if iTerm is already running. - December 14, 2015 (apologies for the delay in merging) V0.5 Release - Added version number and Vítor has done some great work standardising the scripts. No functionality changes in this release - August 14, 2015  Removed bug introduced in last update (quotes around parameter) - August 12, 2015 Fix Whitespace (Vítor Galvão) + Fixed Search for iTerm/iTerm 2 Running (Stuart Ryan) - August 10, 2015 Updated to Fix Multiple iTerm Binaries - August 6, 2015 Initial Release - July 31, 2015  
Donations
If you love the scripts, and get use out of them every day, if you would like to donate as a thank you to buy me more caffeine giving Diet Coke, some Cake, or to put towards a shiny new gadget you can donate to me via Paypal.
 

 
 
Future Updates:
As new versions come out of the 2.9 branch I will keep the scripts up to date, if anyone finds issues with the 2.1 branch please let me know and I will test things out. If there are any changes to the scripts, I will post an update in this thread to let everyone know.
 
If you would like to look at/contribute to the official repository please check it out on Github --> https://github.com/stuartcryan/custom-iterm-applescripts-for-alfred.
 
As always, I welcome ideas/thoughts/feedback etc.
Cheers, Stuart

Howdy All,
This is a quick one I have thrown together for my own use, I am hoping for some feedback on if anyone else would find this useful. I.e. do I keep it to myself, or productionise it properly?
 
I put this together primarily to connect quickly and easily to my Apple Airpods and an Alfred Workflow seemed like a great way to do that. I then expanded this to do hotspots and extra headphones as well.
 
Shoutout goes to Ian Gloude for his code on https://medium.com/@igloude/using-applescript-and-btt-to-make-the-airpods-experience-a-little-bit-better-6e78b12d33bd that makes this work. Essentially all this workflow does is do the clicks in the UI for you. I have logged a RADAR to Apple's BugReporter to request proper programmatic access to such Bluetooth functions also (for good long-term measure).
 
You can grab the beta workflow from: https://web.tresorit.com/l#5nvV-nDObUj8ovGFXYHP5g
 
Setup:
Load up workflow Open Workflow Environment Variables Modify Workflow Environment Variables with your Bluetooth Device Names. PLEASE NOTE - read the notes alongside regarding regular and artistic apostrophes. AirPods especially seem to have artistic apostrophes in their name so you need to make sure you get the right one. Should be good to go  
Usage:
btairpods - connect to your airpods (they must be out of their case) btheadphones - connect to another set of defined headphones btphone - connect to phone network bthotspot - connect to iDevice hotspot (note this forces a several second delay between clicking the WiFi menu and clicking the hotspot as it usually takes a second for the hotspot's to show) dcbthotspot - disconnect from iDevice hotspot

Howdy everyone,
It has been a long time since I poked my head in here, (an equally long time since I have had a chance to maintain my workflows).
 
After changing jobs earlier this year, changing environment, and for a plethora of other reasons, I am now looking to pass the baton so to speak for a number of my workflows and repositories in the hope that one or more people can give them the time they need.
 
Namely these include:
LastPass Alfred Workflow - https://github.com/stuartcryan/lastpass-alfred-workflow Custom iTerm Applescripts for Alfred - https://github.com/stuartcryan/custom-iterm-applescripts-for-alfred Rapid Browser Tabs for Alfred - https://github.com/stuartcryan/rapid-browser-tabs-for-alfred Default Browser workflow for Alfred - https://github.com/stuartcryan/defaultbrowser-alfred-workflow Advanced Google and Apple Maps workflow for Alfred - https://github.com/stuartcryan/advanced-google-maps-alfred-workflow  
When it comes down to it, a career change, organisation change, working environment (Mac to PC) change, has left me with less and less time to focus on these, and I feel it is time to take a step back. This is not to say I won't be back in the future (and I certainly hope I will), but, simply have other areas of focus in life at the moment where I am focusing my efforts.
 
If you are keen/interested/open to taking the baton, please shout out below which of the workflows interests you and I will have a chat with you!
 
Thank you everyone in advance!
Cheers,
Stuart
 
(also a HUGE shoutout to the work of Andrew and Vero for their continued awesome software!)

I'm sure it has been! Can't even imagine!

Howdy Paul,
Thank you for the feedback, I have often wondered if anyone got use out of this particular part of the workflow. So I will certainly take your request into account in future versions. Having just gone through two major releases in one holiday period and exhausting a LOOOOOOOT of Dev time, I don't foresee any major changes (or deprecation of anything) for some time so you are definitely safe for now.
 
Also Glad to hear you are happy with it, haha it is a LOOOOONG labour of love.
Stu

Hi, I just configured your complex and amazing workflow. I wonder if it's possible to simply call up a map of an address, rather than always have to look up directions from one location to another?
 
I see that I can use the "maps" keyword to look up a map of an address without needing directions between two locations. I also see that the "maps" keyword may be deprecated. I'd like to see the functionality of a non-direction map be kept in the future!

We briefly discussed this very theme recently.

Some languages are geared towards certain tasks. As examples, Processing is geared towards making graphics and R is for statistical analysis. This doesn’t mean they can’t be used for other tasks or that other languages can’t do what these do; it means these are optimised for their tasks. “Optimised” might mean a whole lot of things, like having specific tweaks to make accomplishing goals easier and with less code, or make their code run faster.

Then you have general-purpose languages which are exactly what they sound like. To start with, you should pick up a general-purpose scripting language such as Ruby or Python. Those two are pretty sane languages with big communities. By “sane” I mean that most things make logical sense. Yes, there are languages that are inconsistent (insert PHP joke), which predictably leads to frustration. With Ruby, more than once I didn’t know how to do something, though “I wonder if it works this way” and it did. Having big communities means there are a ton of resources to learn from and get help, as well as a ton of already-made code that you can use. Finally, Ruby and Python come preinstalled with macOS, which lowers the barrier of entry significantly.

Scripting languages are easier to pick up because they do a lot of the heavy lifting. They want you to concern yourself with what you want to accomplish, not how. The computer operations themselves are abstracted from you. This comes with a sacrifice in speed but that’s a more than acceptable tradeoff, especially when you’re starting out.

Here’s the piece of advice I wish I’d gotten: don’t fret too much on which language to learn. They share a lot of concepts, and what you learn in one will easily translate to another. As you become proficient in the programming mode of thinking, you’ll find picking other languages becomes easier. Just start with something relatively popular so you’ll have a lot of resources to draw help from.

Finally, I’ll also say the often repeated advice “think of what you want to do and then try doing it” is rubbish. At this point in time you have no idea how simple or complex your idea is, and it’ll be easy to get discouraged. A good learning source will gradually show you what can be done, and you’ll start to see the possibilities from there.

Good luck!

In most respects, the Python requirement is a non-issue, as Python is a default part of macOS. Zero dependencies (outside of macOS and Alfred) is a core goal of the library because it offended my sensibilities to see so many workflows bundling the same stuff over and over again.
 
But the update mechanism is certainly overly dependent on other parts of the library (for today's Alfred). The library is very monolithic because when it was designed, it was necessary to parse info.plist to get data that are now available via environment variables, and I wanted to avoid parsing it multiple times for performance reasons.
 
That's why I'm looking for input to help with designing a more flexible API. Like whether it's worth making update.py work as a standalone updater for GitHub-based workflows, regardless of whether they use AW (or even Python).
 

Marvellous!
 
Don't kill me but I found a minor issue: The most important fallback search (cycling) for dirtw isn't connected:
 

Howdy all,
So, for you fine people who have given me so many awesome workflows, I give you the Advanced Google Maps AND NOW APPLE MAPS Search Workflow available on Github --> https://github.com/stuartcryan/advanced-google-maps-alfred-workflow.
 
A couple of quick things:
Didn't you just release a major update 1.3.0? Yahuh, I most certainly did, however after that some amazing ideas came out of the woodworks, and it became a mere stepping stone to what the workflow is today. Why didn't you wait to release 2.0.0? Quite simply, I thought it was complete, however, like I mentioned above, some GREAT ideas came out in the week after release from some passionate members of the community, and I figured, WHY NOT! In putting these in, I was able to create added flexibility when re-working the code base, to support several features that previously, were not possible. Why 2.0.0 not 1.4.0? The 2.0.0 release has changed a lot, including adding Apple Maps Support, new updating mechanism, all new location for configuration, and other major changes. Hence 2.0.0 seemed more appropriate. Why is there no download link right here where you are reading right now? Ahh now that is a good question, because there are some things you should know first, so jump back to the first post and get all the juicy deets!  
So please enjoy, this release has had EXTENSIVE testing prior to release, I have to say I am pretty chuffed with it all around!
Stuart
 
Version 2.0.0 Changes
Renamed workflow to 'Advanced Google Maps and Apple Maps Workflow for Alfred'. Left bundleID intact deliberately Changed workflow logo to support new multi-brand mix Added feature for custom locations other than 'home' and 'work' Added default transportation mode setting Added fallback location setting in case there are issues with CoreLocationCLI Added hooks for Alfred fallback searches (for example if you load Alfred and just enter an address without invoking the workflow) Added multi-machine configuration parameters and provided a default catchall feature for this Added contact address handler functionality (to enable the workflow to serve as a Contact Address Handler hook) Migrated (future) work and home addresses out of keychain. Added keychain cleanup function once addresses have been manually migrated to workflow environment variables Implemented OneUpdater code by Vitor so updating will be simple as pie Externalised Perl code for much better gitifying, as well as better code reuse Added external triggers for other workflows to hook into Various code cleanups Significantly improved error handling to do things more gracefully Rectified issues with commas in addresses causing things to break a little Other minor bug fixes and improvements as I went along through the code, improved readability also And in case you missed them - Version 1.3.0 Changes
dirfc: Directions from Current Address. See the installation instructions above to install Homebrew and CoreLocationCLI dirtc: Directions to Current Address. See the installation instructions above to install Homebrew and CoreLocationCLI dir, dirfc and dirtc now support Google transit type (walk, drive, pt [public transport] and bike) dir now supports 'here'. Here anywhere in the transit plan translates to the current GPS coordinates using CoreLocationCLI. Technically this probably does away with the need for dirfc and dirtc, but, leaving them there for consistency. dir now supports 'work' and 'home' as modifiers Overhaul of changes to properly use Google API parameters Mass code cleanup and refactoring for simplification. Most flows now leverage the dir base code. Additional error handling implemented surrounding maximum number of waypoints Fixed a bug where special characters would not work in stored URLs Implemented a workflow environment variable for getting a local Google URL Changed to use Alfred's native URL opening functionality, this enables you to select a preferred browser

That is basically what OneUpdater does. You give it the URL of your info.plist and .alfredworkflow file, and when the former changes, it downloads the latter.
 
As far as external dependencies go, OneUpdater has fewer than Alfred-Workflow, which only works with GitHub releases. OneUpdater is a small, self-contained script that doesn’t care which language your workflow is written in or where it’s hosted.
 

Howdy All,
This is a quick one I have thrown together for my own use, I am hoping for some feedback on if anyone else would find this useful. I.e. do I keep it to myself, or productionise it properly?
 
I put this together primarily to connect quickly and easily to my Apple Airpods and an Alfred Workflow seemed like a great way to do that. I then expanded this to do hotspots and extra headphones as well.
 
Shoutout goes to Ian Gloude for his code on https://medium.com/@igloude/using-applescript-and-btt-to-make-the-airpods-experience-a-little-bit-better-6e78b12d33bd that makes this work. Essentially all this workflow does is do the clicks in the UI for you. I have logged a RADAR to Apple's BugReporter to request proper programmatic access to such Bluetooth functions also (for good long-term measure).
 
You can grab the beta workflow from: https://web.tresorit.com/l#5nvV-nDObUj8ovGFXYHP5g
 
Setup:
Load up workflow Open Workflow Environment Variables Modify Workflow Environment Variables with your Bluetooth Device Names. PLEASE NOTE - read the notes alongside regarding regular and artistic apostrophes. AirPods especially seem to have artistic apostrophes in their name so you need to make sure you get the right one. Should be good to go  
Usage:
btairpods - connect to your airpods (they must be out of their case) btheadphones - connect to another set of defined headphones btphone - connect to phone network bthotspot - connect to iDevice hotspot (note this forces a several second delay between clicking the WiFi menu and clicking the hotspot as it usually takes a second for the hotspot's to show) dcbthotspot - disconnect from iDevice hotspot

@deanishe Alfred doesn't unsubscribe, but idles on the events, only acting on the grouped events when they become relevant (i.e. Alfred needs the changes). Alfred only subscribes to the top level Alfred Preferences file, not multiple paths, so this will be why there may be reload issues with symlinked workflows.
 
I can see that Alfred needs these things:
 
1. Setting a workflow configuration variable, which will write the variable to the info plist.
2. Forcing a reload of a workflow, which will get Alfred to reload a workflow e.g. if a symlinked info plist is externally updated via github
 
It pains me to say that, for now, this may be done through Alfred's AppleScript interface, as the framework for this already exists. I do have much bigger plans for the future for this area though.

I wasn't sure whether to post this in here or in Feature Requests. Ultimately, I chose here because the workflow configuration sheet and workflow variables provide a very handy way to configure a workflow, but its utility as a settings store is significantly limited by the fact that Alfred doesn't notice when info.plist was altered by something other than itself.
 
Specifically, I'm thinking about scenarios like the one I outlined in the Workflow Variables HOWTO, where a workflow developer would like to offer a way to toggle a setting on/off or add an API key via the workflow's own UI, rather than asking users to crack open Alfred Preferences, hunt down the workflow and edit its configuration sheet.

It's a better user experience, allows the developer to validate the input, and knowledge of the existence of the configuration sheet is far from universal (a more obvious "settings in here!" icon might help).

The problem is that Alfred takes several seconds to notice that info.plist has been changed by something other than itself (possibly several minutes if the workflow is symlinked), so the setting doesn't immediately stick and the workflow displays incorrect info or straight-up doesn't work until Alfred notices.

Practically, this makes the variables in the configuration sheet read-only.

This is a great shame, as it means that if you want to provide the ability to alter a workflow's settings from within the workflow, you have to forget about the configuration sheet and implement the whole thing yourself  

Ideally, Alfred would either (a) check the modtime of info.plist every time it sets the workflow variables or (b) provide some official means for workflows to edit their own settings, e.g. /Applications/Alfred\ 3.app/Contents/MacOS/Alfred\ 3 --set "name" "value" (Alfred can grab the workflow's bundle ID from its own workflow variable! How cool is that?)

*cough* I was TOTALLY checking if you were all paying attention! That has now been fixed LOL thank you!

Great work, thanks! I've just done very limited testing (about 10 minutes) but I can confirm that it now works with Swedish characters (å, ä and ö), and all the functions I've tried seem to work perfectly!

OOOH noted, I will have to see what I can do about this, may simply need to UTF-8 encode everything more diligently. Will see what I can come up with.

Thanks for the update! It works great for me (OS X 10.12.2, Alfred 3.2.1).
 
There is one minor issue but with a simple workaround, the mapsethome/work commands do not seem to support international characters (in this case Swedish characters å, ä, or ö). However, Google finds correct address anyway so the use of international characters does not seem necessary.

Howdy all,
I have put together a new beta release and I am hoping a couple of people could test this out for me please prior to releasing a full update:
 
https://dl.dropboxusercontent.com/u/9093155/Advanced Google Maps Search 1.2.0beta.alfredworkflow 
 
Changes in this beta include:
I have added a Workflow Environment Variable for setting your Google Locale: It is quite rudimentary at the moment, but in essence if you (for example) set the variable to the domain for your locale. For example 'com.au' it will use google.com.au if you use 'com.tw' it will use google.com.tw. Changed to use Alfred's native 'Open in' functionality rather than relying on the 'open' command for native configurability in Alfred (if you wish to force a particular browser, other than the default). If a couple of people would like to test and report back OK, I will happily release a full update.
Cheers,
Stuart

Ok.. found a workaround.
 
Seems the index searches here also (when using spotlight or alfred):
/Users/obazavil/Applications (Parallels)/
 
And puts the stuff from that folder before the native chrome
 
so... i suppose rbt searches for the first chrome result, finds the parallel one, try to interact with it and crashes
 
what I did was rename chrome from the VM.. i dont need it that much in the meantime  and now everything works

@stuartcryanReally useful script - cheers for sharing.
Still working well with Alfred v3.1

Just signed up to congratulate you for this fantastic workflow!
 
Regars.

Howdy my good man, so sorry I missed this.
I have logged two bugs for you:
1. Weird search issue --> https://github.com/stuartcryan/lastpass-alfred-workflow/issues/12
2. Shameful SHAMEFUL typo LOL --> https://github.com/stuartcryan/lastpass-alfred-workflow/issues/13
 
Thank you for reporting them, I have a week off as of this evening so hopefully will be able to get to them.
Cheers, Stuart

Change your default web browser quickly and easily from within Alfred.
Simple yet effective, this workflow enablea you to easily change your default browser. The official repository is located on Github --> https://github.com/stuartcryan/defaultbrowser-alfred-workflow where any issues can be logged on the issue tracker. I have also put this workflow on Packal.
 

Update Version 1.2 released September 10, 2015:
What has changed:
Feature: Support additional browsers - added FirefoxDeveloperEdition and Webkit Nightly Build Update Version 1.1 released August 8, 2015:
What has changed:
Feature: Support additional browsers - added Chromium, Canary and SeaMonkey Feature: Only show installed browsers Feature: Indicate which browser is the current default Feature: Added hotkey assignments (to launch workflow, launch with "chrome", and launch with "safari") Improvement: Renamed description in Alfred to simply "Default Browser" Improvement: Improved failure feedback Improvement: Major code refactor to remove duplication and speed up the workflow Improvement: Added an icon to the workflow Improvement: defaultbrowser binary has been updated to better support integrating. This code has been put into a pull request for the official publication of defaultbrowser.
Workflow Details:
A simple workflow to allow quick and easy changing of the default browser on OSX using a workflow in Alfred.
Installation
Download the .alfredworkflow file or you can get it on Packal. Run to import into Alfred Donations
This workflow represents many hours effort of development, testing and rework. The images that have been licensed for this workflow from DepositPhotos also needed a bit of my moolah. So if you love the workflow, and get use out of it every day, if you would like to donate as a thank you to buy me more caffeine giving Diet Coke, some Cake, or to put towards a shiny new gadget you can donate to me via Paypal.
 

 
You should also consider getting into contact with Margus Kerma and donating to Margus also for the work that has bene put into the defaultbrowser binary.
Usage
db < browser > Note - if you try to set the default browser that is already active as the default you will just get a notification. Browsers currently supported:
Chrome Firefox Opera Safari Chromium - New in V1.1 Canary - New in V1.1 SeaMonkey - New in V1.1 Screenshots

 

 

 

 
Troubleshooting
If you are finding that you are seeing browsers listed that you have installed previously but no longer have on your system you will need to clear out all your default handlers.
Unfortunately, this is the only solution I have found to date, you should research it in depth before you use it. The following command will re-initialise all the "handlers" OSX knows about and will therefore resolve the issue, it will also likely require you to set up all your custom file associations again.
In other words... you do this at your own risk, I do not support this in any way shape or form...
The command you will need to run on the terminal is: lsregister -kill
 
Contributing
Fork it! Create your feature branch: git checkout -b my-new-feature Commit your changes: git commit -am 'Add some feature' Push to the branch: git push origin my-new-feature Submit a pull request Change Log
Version 1.2 - Feature ReleaseFeature: Support additional browsers - added FirefoxDeveloperEdition and Webkit Nightly Build  Version 1.1 - Feature ReleaseFeature: Support additional browsers - added Chromium, Canary and SeaMonkey Feature: Only show installed browsers Feature: Indicate which browser is the current default Feature: Added hotkey assignments (to launch workflow, launch with "chrome", and launch with "safari") Improvement: Renamed description in Alfred to simply "Default Browser" Improvement: Improved failure feedback Improvement: Major code refactor to remove duplication and speed up the workflow Improvement: Added an icon to the workflow Improvement: defaultbrowser binary has been updated to better support integrating. This code has been put into a pull request for the official publication of defaultbrowser. Version 1.0 - Initial Release Credits
defaultbrowser binary for OSX has been created by Margus Kerma.
Margus has been kind enough to permit me to include the binary for defaultbrowser as part of this workflow to make distribution significantly easier. For any issues with the defaultbrowser binary please log these to the official DefaultBrowser Issue Tracker. DefaultBrowser Alfred workflow created by Stuart Ryan. If you would like to get into contact you can do so via:
@StuartCRyan on Twitter Stuart Ryan on LinkedIn Technical Notebook Blog License
With the exception of the workflow logo, this Alfred Workflow is provided free of charge under the GNU GENERAL PUBLIC LICENSE Version 2 June 1991.
The workflow logo is licensed only for use in this workflow and must be changed if the workflow is forked in the future.
The workflow logo has been licensed from DepositPhotos to Stuart Ryan.