Jump to content

stuartcryan

Member
  • Posts

    131
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by stuartcryan

  1. 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!)
  2. Hi @Mehdi and @mikeylu, Can you please make sure the scripts in the workflow directory are executable (in a terminal chmod a+x <scriptname> specifically both applescript.scpt and passwordInput.osascript and let me know how that goes? Cheers, Stuart
  3. Hi! Could you possibly post a screenshot of your bluetooth menu opening the connect submenu (I am wanting to see if there is something different in your menu than what I am seeing. Also what version of MacOS are you on? Cheers, Stuart
  4. 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
  5. I had a look at the API reference as I didn't remember seeing that as an option. At this point in time, there is no option to force the flights as a travelmode https://developers.google.com/maps/documentation/urls/guide#directions-action. So, I have logged this as a feature request on my own GitHub instance to track https://github.com/stuartcryan/advanced-google-maps-alfred-workflow/issues/20, and have also taken a step further and added the feature request to Google's issue tracker https://issuetracker.google.com/u/1/issues/71937166. Starring the second and adding a comment +1 (with any other comments, on the GitHub issue) would be helpful. Alas this is one that I won't be able to do until Google makes the change, and there is no guarantee, but I have tried my best. Duly noted and that is a good call, I will update everything now, and the info in the readme will update on the next version. You are most welcome Please consider a donation if you can, this one has been an EPIC EPIC EPIC amount of work and takes a lot of time even after to give support, so donations are always welcome.
  6. Hi Guy, When you try 'dirfw pt DESTINATION ADDRESS' can you please open up the debugger in Alfred (look for the little bug in the top right of the workflow page) and check if there is any error output there? Also the modifiers can only be used as the first point so you have to have 'dir drive ORIGIN to DESTINATION' not 'dir ORIGIN to DESTINATION drive'. It should also give you the URL that is used (if you set to all information), and I would be keen to grab the URL that it generates (you can redact the source and destination address out). Also are you using Google or Apple maps? Cheers, Stuart
  7. Oh BOOOOOO!!! LOL after ALL that *cries a little*! With that said 2.0.1 released, you can either wait until the updater runs or grab it directly!
  8. 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
  9. Minor Bugfix just released 1.3.1 to address an issue in dirfh and dirfw where they were falling back to 'here' not 'home' and 'work' respectively. Available at https://github.com/stuartcryan/advanced-google-maps-alfred-workflow/raw/master/Advanced_Google_Maps_Search.alfredworkflow or via Packal.
  10. Eggsellent! Glad you like it. I have responded to your github issues, all seem completely logical to me so I can see what I can do on them. On the externalising of the Perl, that would actually be rather logical and I had not considered that, I think that would be logical now the flow has matured more. Also, anything that helps reduce the duplication is a bonus. I managed to pull about 80% of the duplication in this new version, but would like to remove as much as possible. I will have a look at this for the next version also. And thank you! I know Perl can be a NIGHTMARE, hence I like to make it as readable and maintainable as possible. If you have any tips, or anything you think could be cleaned up, I am always all ears.
  11. All righty! Ladies and gentlepeoples, we have 1.3.0 released as of today available HERE (and on Packal). First up, apologies you will need to re-set up your work and home addresses, there was no avoiding this, if you don't you will get very strange results in Google! 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 New things you can do: dir to to etc (seperate multiple addresses with " to " minus the quotes, and you will get a multiple location search) [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 ' will give you public transport directions. This also works with 'dir' and multiple waypoints. [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 example 'dir origin to waypoint 1 to waypoint 2 etc to destination' This release has been a LOT of work, and a long time coming. if you use it regularly, please consider a donation. Donations This workflow represents many many hours effort of development, testing and rework. 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 (preferred) 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.
  12. Woohoo, great to hear, sorry that one took a significant amount of time to fix. I will leave it a few more days and if it doesn't give me any grief, will release a new version. Thank you for the feedback! Cheers, Stuart
  13. 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
  14. For those of you that have had problems with special characters ( @cands, @jhinden, @xilopaint) , I now have a fix for that too. Please see 1.2.3_Beta2. Please note, this is a non-backwards compatible version, which means you will need to set up your work and home addresses again. I have to encode and decode them, so if you try to use the workflow without setting them up... the addresses Google gets for work and home will *not* be what you are expecting. This also fixes a couple of bugs in the 1.2.3 update caused by an automated code indenting script I used (yep, lesson learned, just do it myself LOL). New version 1.2.3Beta2 available at https://web.tresorit.com/l#Fsa5vI-klGhN0BypfIXQjw. REMEMBER YOU MUST SET UP YOUR ADDRESSES AGAIN! Also, please read the notes in the workflow readme (on the parameters set up page). Thoughts welcome!
  15. Version 1.2.3 Beta - Released December 25th 2017. You can get this from [REDACTED, PLEASE SEE NEW POST BELOW FOR BUGFIX VERSION - I made a slight booboo when indenting which causes a problem in the Beta1 Release] (download link expires in 90 days, I will push it out formally before then) Host of new features: 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. overhaul of changes to properly use Google API parameters All flows now support the 'dirX walk|bike|pt|drive' modifier YEP you can now tell Google what transport form you wish for New basic utilisation of dir: Basic utilisation: dir ORIGIN DESTINATION Advanced 1: dir ORIGIN WAYPOINT1 WAYPOINT2 .. WAYPOINT9 DESTINATION Advanced 2: dir walk|bike|pt|drive ORIGIN DESTINATION Advanced 3: dir home|work DESTINATION Advanced 4: dir ORIGIN home|work Advanced 5: dir ORIGIN WAYPOINT1 work|home .. WAYPOINT9 DESTINATION Advanced 6: you can use 'here' in place of any ORIGIN, DESTINATION or WAYPOINT to pull the current location using the CoreLocationAPI if set up. Hoping to find a few brave souls to give this a bit of a whirl in a wider audience base.
  16. 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.
  17. I just had a quick look and notice that Apple does have URL parameters... it would require some tweaking, probably a few hours plus some testing for good measure. https://developer.apple.com/library/content/featuredarticles/iPhoneURLScheme_Reference/MapLinks/MapLinks.html Cheers, Stuart
  18. 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
  19. Hi Ae6dx, No there is not, this has been deliberately excluded as a security measure. The workflow itself never stores or saves the password, it simply tells the LastPass CLI to invoke a script requesting the password (and hence never actually has visibility of the password itself). Cheers, Stuart
  20. Now THAT is an interesting one... I will have a think and see if I can figure out a way to exclude the Parallels folder from the searches. Thank you for the info (that will make life a lot easier).
×
×
  • Create New...