stuartcryan

Hi Andrew, Just reporting back on something odd. I installed the Beta at work, it synced with Dropbox OK. When I got home I forgot that I had upgraded to a Beta but started noticing some issues, the custom terminal scripts had gone missing, and my default "launch alfred" hotkey had changed back to the default. Just thought I should give you a heads up. Cheers, Stuart [update] After a full system restart, this seems to have resolved the issue and the preferences have now loaded correctly.

WOOHOO haha glad to hear it, nice to know I can help out (if you have any suggested modifications to the scripts please let me know... I just threw together pretty basic ones...). Have to say I am stoked with the 2.9 one now though... not getting the double terminal opening /dances

Hi Andrew, I am game downloaded and will let you know if I hit any issues. Cheers, Stuart

Hi Bill, I actually stumbled across this one --> http://www.alfredforum.com/topic/1775-search-emoji-codes/?hl=emojiBy Carlos in the forums recently... I think it might do what you are looking for Cheers, Stuart

No worries at all glad that someone else can get usage out of it

I know I am probably talking to myself here... so I will just say, new version released, check out the github repo for details https://github.com/stuartcryan/custom-iterm-applescripts-for-alfred

All good you caught me on lunch. Can you please private message me with the outputs of the following terminal commands: perl --version system_profiler SPSoftwareDataType cpan --version cpan -l (will be a long output, may need to send as a file, message me for my email address) sudo cpan -l (again, will potentially be quite a long output as above.

Hmm that is a weird one. General way to fix all permissions issues in OSX is to run Disk Utility, select your Macintosh HD (or whatever you have renamed it to) and click Repair Disk Permissions. Please give that a go and let me know how you go. Cheers, Stuart

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.

All righty and now I have updated the scripts... made them more awesome and even added one for iTerm 2.9 https://github.com/stuartcryan/custom-iterm-applescripts-for-alfred/tree/master Not sure the best way to publish this but if anyone has any issues let me know and I will try to tweak the scripts further. Cheers, Stuart

OK once iTerm decided to update itself to 2.1.1 it stopped working again. SO here is a new version and even BETTERER this works around the age old issue of the default terminal always opening [edit] helps if I post the full thing. I might throw this together into a git repo as I am sure it will need updating on a more regular basis on is_running(appName) tell application "System Events" to (name of processes) contains appName end is_running on alfred_script(q) if is_running("iTerm") then run script " on run {q} tell application \"iTerm\" activate tell the first terminal set mysession to (launch session \"Default Session\") tell mysession write text q end tell end tell end tell end run" with parameters {q} else run script " on run {q} tell application \"iTerm\" activate tell the first terminal tell the last session write text q end tell end tell end tell end run" with parameters {q} end if end alfred_script

Hi Andrew thanks for that, With those links I was able to come up with the following which seems to works around it for the time being for the current v2 of iTerm: on alfred_script(q) tell application "iTerm" activate set myterm to (make new terminal) tell myterm launch session "Default Session" tell the last session write text q end tell end tell end tell end alfred_script

All righty, seems I cant message you on the PM system: So... instead could you please add me on Skype and I can chat to you there. My Skype username is StuartCRyan Cheers, Stuart

Hi Danjng, You are the second person to report this... will DM you as I will likely need to set up a Teamviewer session with you so I can have a look at what is going wrong. Cheers, Stuart

Hi Team, I seem to be having a bit of an issue that has cropped up in the last few weeks, I am not sure exactly when it started but the symptoms are this: 1. When I try to execute a terminal command with '.< command >' or a workflow tries to execute a terminal command... if I don't already have iTerm open, nothing happens at all. 2. If I manually open iTerm and have it running in the background... everything runs fine. This seems to occur across all three of my Macs. Versions: iTerm2 2.1.1 OSX: 10.10.4 Alfred: 2.7.1 (387) I have had a look and turned on all info for one of the flows and it does not error out at all, this seems to execute successfully: [iNFO: alfred.workflow.input.keyword] Processing output 'alfred.workflow.action.terminalcommand' with arg '' But strangely iTerm2 is never opened. It seems the iTerm2 program is now just called iTerm in my Applications folder, not sure if this has affected things at all (or if it always was). I have also checked the system console and no errors seem to be outputted to any system logs during the time I was testing. Look forward to hearing from you. Cheers, Stuart Update: All righty and now I have updated the scripts... made them more awesome and even added one for iTerm 2.9 https://github.com/stuartcryan/custom-iterm-applescripts-for-alfred/tree/master Not sure the best way to publish this but if anyone has any issues let me know and I will try to tweak the scripts further. 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 BuildUpdate 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.

OK so it seems that El Capitan is not yet supported on VMs in Parallels. As soon as it is I will look into this (but don't have a machine to spare to install the beta just yet). I will keep you posted.

Hi Cka304h1k, Thanks for that, I will have to see if I can spin up a VM and upgrade it (not tried this before). Will keep you posted. Cheers Stuart

Thanks Vítor you are a gentleman and a scholar Stuart

[update 12th July 2015 - Version 1.1 Release] Howdy all, I am happy to announce this workflow is now up on Packal --> http://www.packal.org/workflow/lastpass-cli-workflow-alfred (can be downloaded from here) Version 1.1 Changes: Removed code that worked around an old buggy version of pinentry Fixed incorrect handling of no search results found (previously reported CLI tools were not installed)

Working with Dimitri on this offline (as it is requiring additional information) though it appears to be an isolated issue with the brew install I will keep everyone posted.

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 2.0.1? @deanishe found a bug in his favourite part of the flow he had been waiting for... it has now been squashed! 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 Easy directions from or to multiple locations, using either Google Maps or Apple Maps. Now includes custom locations in addition to just home and work, auto updating, and a wealth of new features for you to sink your teeth into. Getting to Know the Flow - Course available for $14.99USD With the explosion of features, added configuration complexity, and awesomeness of the 2.0.0 major release (and overhaul), I have opted for a different tact, to ensure the support overhead is limited. I have put together an hour long course for only $14.99USD that covers off every configuration option of the workflow, how to get up and running, getting into the advanced nitty gritty, and so on. The course will be updated as any new usability or training needs are identified, and I will commit to the course being updated through the entire V2.0.0 release. I do reserve the right to extend that to the next release if I later choose. Version 1.3.0 and version 2.0.1 represent almost the entirety of my holiday break over December-2017 and January-2018. I would anticipate I have over $6000 in time into this flow for these two versions alone, plus costs for the new logo, and costs for Closed Captioning. So don't delay and check out the course, there are a few videos set to preview so you can try before you buy! Donations Alternatively if a course is not your thing... You can just donate to me directly! If everyone who downloaded gave $20, that would make me a very happy camper and give me something back for my time, it would also enable me to have a custom icon set created for the flow. So if you love the workflow, get use out of it every day, and would love to see me continuing development, a donation is a great way. You can either donate to me via Fundly which gives the option of a re-occurring donation and also has some suggestions, donate to me via Patreon (if that is your preference) or donate to me via Paypal which is nice and easy. 2.0.0+ Release Compatibility Information In 1.3.0 the home and work locations, required setting up again due to a bug with special characters. In 2.0.0 the home and work locations have been moved out of the keychain (which was a legacy method of handling them before Alfred had workflow environment variables). Old locations can still be used as they would have without further intervention. However, the mapsethome and mapsetwork commands have now been removed. To add/update these now you must do so on the workflow environment variables config screen. I would also recommend you run 'zcleanmapsoldaddresses' to remove the old addresses from your Apple keychain. Installation Ensure you have Alfred installed with the Alfred Powerpack License Download the Advanced_Google_Maps_Search.alfredworkflow file Open the .alfredworkflow file to import into Alfred Set up the workflow configuration parameters as you desire (see below for additional details), by clicking on the little [X] in the top right hand of the Workflow page in Alfred Complete the advanced steps below to add additional (and awesome) functionality Current Location Feature Installation and Configuration If you wish to use the 'Directions from Current Location - dirfc' command or the 'here' modifier, you will need to also install homebrew and the CoreLocationCLI package. Install Homebrew using instructions from https://brew.sh/ Install the CoreLocationCLI utility by running the following command in a terminal 'brew cask install corelocationcli'. Check your installed location by running 'which CoreLocationCLI' Ensure the workflow environment variable on the Workflow Configuration screen matches the installed location. Contact Address Handler Configuration If you wish to use this workflow to handle directions to a contact's address you may do so by completing the following additional steps. In Alfred's Preferences click on Features --> Contacts Double click on the 'Address' field In the dropdown, select "Search Contact Address with Advanced Google and Apple Maps Search" Ensure you correctly configure the contactHandler parameter as per the instructions under the Configuration section. Fallback Search Setup If you wish to use this workflow to handle fallback searches in Alfred, you can now do this too! In Alfred's Preferences click on Features --> Default Results Click the button to 'Setup Fallback Results' Click the small + sign to add a new record Select any of the available fallback searches provided by the workflow to add them to your personal fallback search results. Configuration Explanation of each of the Workflow Environment Variables contactHandler: Used as the default mechanism to handle Contact address searches. Supports two formats including "drive here to" (current location to Contact's address) "drive to here" (Contact's address to Current Location) or "('computerName:drive here to','default:drive here to')" CoreLocationCLIBinary: Defines the location of the installed CoreLocationCLIBinary. Supports two formats including "/usr/local/bin/CoreLocationCLI" or "('computerName:/some/other/location/CoreLocationCLI','default:/usr/local/bin/CoreLocationCLI')" currentLocationFallback: Used as the fallback address in case CoreLocationCLI is not installed, or fails (especially if WiFi is unavailable, or turned off). Supports two formats including "Some Address in Some State 20023" or "('computerName:home','someOtherComputerName:Some Address in Some State 20023','default:work')" customLocations: Supports custom location modifiers for all dir* commands. Please note, this does not dynamically add new dirfx or dirtx commands. Must be formatted in the following fashion: "('gym:49 Queens Rd, Five Dock NSW 2046','school:1A Harris Rd, Five Dock NSW 2046')" defaultTransportationMode: Defines the default transportation fallback mode if none is specified at runtime. Possible values include: "pt" for Public Transport, drive, walk or bike. Supports two formats including "bike" or "('computerName:pt','someOtherComputerName:walk','default:drive')" googleLocal: Defines which Google Locale to use such as 'com.au', 'com.tw' or 'com' as some examples. Supports two formats including "com.au" or "('computerName:com.au','someOtherComputerName:com.tw','default:com')" homeAddress: New storage location for Home Address. Supports two formats including "Some Address" or "('computerName:Some Address','someOtherComputerName:Another Address','default:A Third Address')" workAddress: New storage location for Work Address. Supports two formats including "Some Address" or "('computerName:Some Address','someOtherComputerName:Another Address','default:A Third Address')" mapsHandler: PLEASE NOTE this only supports a value of either "Google" or "Apple" and may not have a computer specific value. Recommended Example Configuration for Workflow Environment Variables contactHandler: ('default:drive here to') CoreLocationCLIBinary: ('default:/usr/local/bin/CoreLocationCLI') currentLocationFallback: ('default:home') customLocations: ('gym:GYM ADDRESS','school:SCHOOL ADDRESS') defaultTransportationMode: ('default:drive') googleLocal: com homeAddress: Your Home Address workAddress: Your Work Address mapsHandler: Google Notes on Caveats with Apple Maps Apple Maps does not support as many functions as Google Maps and there are two main areas that will cause graceful errors when using Apple Maps. If you attempt to use the 'bike' modifier anywhere, Apple Maps does not support such directions and therefore we gracefully tell you this won't work. Secondly, Apple Maps does not support waypoints or building up an itinerary. Therefore if you attempt to use the dir command with more than just an origin and a destination (such as home to shops to work), we will gracefully error out and tell you such a function is not possible. Usage dir to to etc (seperate multiple addresses with " to " minus the quotes, and you will get a multiple location search when using Google Maps only) [NEW] dir now does all the heavy lifting. You can use the modifiers 'here' (current location, must have CoreLocationCLI installed), 'work' and 'home' in any query. For example 'dir home to work to new york'. [NEW] dirfc this will use your current location (WiFi card must be active) to the destination. [NEW] dirtc Show directions from query to current location [NEW] All commands now support the following modifiers: walk, bike, drive, pt (public transport). The modifier can be invoked by 'dirX ' e.g. 'dirfw pt home ' will give you public transport directions. This also works with 'dir' and multiple waypoints. Please note, the transport modifier must be the first parameter you pass to any dirX command, for example 'dirfw home pt' is not valid. [NEW] Localisation now defaults to USA, hence make sure you update workflow parameters if you wish to use a different country code on the Google URL. dirfw Show directions from Work to address dirfh Show directions from Home to address dirtw Show directions from query to Work address dirth Show directions from query to Home address trafficw - Show traffic from Home to Work traffich - Show traffic from Work to Home [NEW] dir now supports up to 9 waypoints for Google Maps. For example 'dir origin to waypoint 1 to waypoint 2 etc to destination' Integration hooks for Other Workflow Providers This workflow now supports integration using external nodes. They suppor the same methods and modifiers as described for the rest of the workflow. This means you can now hook into this workflow to leverage the 'here', 'work', 'home' and other custom modifiers set up by a user, as well as provide routing directions based on your input. Please review the workflow for each of the hooks available. History Version 2.0.2 Fixed comma issues in all the dirfX commands by quoting the strings Version 2.0.1 Fixed dirtw bike command... it hadn't been connected... after all the testing! #oops Thanks @deanishe Version 2.0.0 Renamed workflow to 'Advanced Google 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 Released an hour long course to help people get the workflow up and running. Version 1.3.1 Fixed dirfh and dirfw to actually use home and work respectively, not here. #oops Version 1.3.0 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 Version 1.2 - Actually this never made it out of beta, despite working, I have been kinda busy. Version 1.1 - Set default search to be google.com rather than google.com.au Version 1.0 - Initial Release Credits 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 Released under the GNU GENERAL PUBLIC LICENSE Version 2, June 1991

Hehe trumpet away I had seen that and it looks like it is the most extensive one available and it WOULD be good to finally learn some python too... That would make a lot of it much easier. *makes notes* hehe thanks deanishe

Howdy all, So I use Atlassian JIRA at work and in personal aspects of life. I am coming up with a design to allow quick creation of new tickets and searching of existing tickets (as a starting point). Not sure at this stage how extensive the workflow will be (will greatly depend on how long it takes to develop the minimum features I require and then how much I can get done before the start of next semester . Basic functionality I am looking at thus far is: Cache available projects Cache available assignable users (possibly/depending on how well this would work with thousands of users... may also provide the option to "create" a local reference to a user as this could just get messy... yet to be decided) Cache available Sprints (depending on if these can be listed with the api) Cache project available issue types (depending on what can be done with the API) Set active project (i.e. the one you want to work with) Search active project Search all projects Create issue in active project Assign issue on creation with a flag Set up some issue defaults (for those people that have some fields mandatory) Possible Extension Ideas: Set active issue Log comment on active issue Log work on active issue Re-assign issue Assign issue to sprint Set issue start time Set issue finish time Use oauth for Authentication rather than Apple Keychain and POST parameters (as per https://developer.atlassian.com/jiradev/api-reference/jira-rest-apis/jira-rest-api-tutorials/jira-rest-api-example-oauth-authentication ) My current language of choice is perl but I am going to have a look at ruby or python as well... open to ideas/recommendations if anyone has experience with REST web services and can recommend any over the other. So... who out there uses Atlassian JIRA, what would you look for... throw your ideas at me.. and GO! Cheers, Stuart

Howdy David, Thanks for the feedback. I can definitely appreciate the methodology and thinking behind why developers do this as a "best practice". I guess what I was identifying was, at the moment there *is* no standard and for workflows that do not need to store complex settings that is fine and they can be stored locally. However for workflows that require some sort of configuration it would be ideal to enable (if selected) the ability for settings to be synced. I guess I see several ways of tackling this: 1. Workflow developers design a settings workflow as part of the workflow, which gathers and stores a new folder location to reference the settings (this then needs to be configured, per computer, per workflow). The downside here, is this would add increased complexity to workflows, these may be written in many different languages, and may work slightly differently between each workflow. It also requires the addition of a large portion of new code to workflows to enable easy definition of where it should store its data (i.e. to make it user friendly). 2. Community designs a "settings" workflow which standardises several such configuration settings, user then configures on each computer and other workflows can reference/leverage the configuration generated. Benefits here is things are standardised, if the workflow is leveraged correctly then a user should only have to configure it once for each machine. Downside is that this may use a language that not everyone is familiar with, requires workflows to rely on something that may or may not be there (i.e. settings workflow may not be installed). 3. Alfred adds a global setting which lets you specify a folder (separate to dropbox) where workflow data can be stored. It is then put forward as a new standard that before defining your data storage location you check if {datafolder} is specified (as an example) if it is, you use that as the base folder, if it is not, you use whatever folder you wish to specify. This would require a bit of smarts around it, for example if someone does not have it set, then later decides to, alfred should copy all the existing data to the new location. However this is far preferable having a standard supported mechanism to do so, rather than relying on each workflow to manage this behaviour itself. 4. Alfred automatically stores the data folders in Dropbox when Dropbox sync is selected. This is just another way of looking at it and may have pros and cons, it would expose in the same way the {datafolder} parameter which workflows could then check... if it is set... use that location (ie. into the dropbox folder) if it is not, then do as you wish. With either option 3 or 4 I would also anticipate a flag that could be set on a workflow (i.e. through the gui, same page as the Workflow Details) which lets you flag it as "separate instance" i.e. even if you are syncing all the data, you want this computer's instance of the workflow to have its own settings, then Alfred would simply append to the {datafolder} parameter a computer UUID or similar. I guess what I hinting to is... there is no currently supported and standardised mechanism to support the syncing of data for workflows that require it. I think a lot of the power of Alfred comes from it handling such heavy items under the hood. While it would be possible to do items 1 or 2 they are less than ideal and will likely result in some difficult to use/complex and non-standard workflows where as by putting some basics into the Alfred interface, the application can capture the detail of how the user wants synced settings to operated (which it already does but just not for the workflows) and expose that in a standardised and supported manner. Look forward to your thoughts. Cheers, Stuart