Jump to content


  • Posts

  • Joined

  • Last visited

sphardy's Achievements


Member (4/5)



  1. Hi Andrew New build fixes the issue - I see the enhancement also and that shows Alfred is finding the 1Password file in the 3rd Party Integration folder. Thanks for the fast fix
  2. thanks for the pointer - I had missed that post, but gone thru the same debug steps to ensure the bookmark file was being correctly generated. I've added to the thread that I appear to be experiencing the exact same issue.
  3. Hello While I have seen this issue posted previously and resolved, it appears to have returned. I have successfully used 1Password with Alfred for a number of years, but it has 'stopped working' for me recently - the 1Password bookmarks are not loaded into Alfred and instead I see the error "unable to find 1password data" in Alfred Settings -> Features -> 1Password (Red text in lower right of window) I have the "Enable 3rd party app integrations" option turned on in 1Password and I have the bookmarks-default.json generated in the expected location: ~/Library/Application Support/1Password 4/3rd Party Integration/bookmarks-default.json In Alfred I have tried both enabling autodiscovery and also entering the above path manually, but the "unable to find 1password data" error remains Software versions reported as follows: Alfred 2.8.1 (425) 1Password 6 Version 6.0.BETA-2 (600002) OSX 10.11.2 I appreciate I am using a beta, however I have seen no references anywhere to Agilebits changing their 3rd party integration support and have successfully run with their betas before. I would appreciate any suggestions
  4. FYI: I have a markdown ruby script I run via Alfred - actually a bash script in alfred that just passes selected text to the ruby script. That too was failing since upgrading to Mavericks with the raw ruby script just generating errors. Updating the script to specifically call Ruby 1.8 as Clinton suggests immediately fixed the issue.
  5. Think I've found the issue. I use the Finder extension TotalFinder - I tried disabling that and Alfred started to respond immediately again . It also responds immediately after restarting TotalFinder, so something odd appears to have happened, perhaps after a recent update to TotalFinder, which a restart has cured. Note that I've run TotalFinder for as long as I've run Alfred - all without issue - so I'm hoping this was a spurious issue and not some new general incompatibility with TotalFinder
  6. I used the incorrect term - this is to action files selected in Finder. When files are selected and I press cmd+opt+\ then it takes 10s for the Alfred window to appear Same is true if I use cmd+opt+/ to navigate to a file (which works instantly) and then press Fn to open the same action window
  7. Hi I noticed recently that it takes 10 seconds for the file buffer actions window to open when using the Opt+Cmd+\ hotkey on a finder selection. (Literally 10 seconds - I've timed it) I am running the latest 2.0.3 release and have restarted Alfred after temporarily removing my sync'ed preferences to see if any custom workflow was the cause - the problem remains. I also downgraded to 2.0.2 but that didn't help either. Finally I cleared the caches - again no change. (Edit: Removing ~/Library/Application Support/Alfred 2 doesn't fix the issue either - feels like I've effectively completely reinstalled Alfred and the problem remains) The standard Alfred popup is instantaneous as always as is the file search window triggered with Opt+Cmd+/ Could someone please advise? Thanks MacBook Pro running OSX 10.8.3
  8. Hi According to a post by Vero, v2.0.3 is available as a pre-release: However I have no such "pre-releases" option in v2.0.2 - where would I find this? ///P
  9. Yeah - just spotted that (was editing my last msg as you posted, but thought it was a typo rather than intentional) I'm up to date with the other flows so no issue Thanks again for all your help
  10. Doh! Should have thought to look - yup we have an error: [com.danielsh.alfred.alleyoop: Evernote 3.5 failed with error: 'download_url' (2013-04-05-10:38:35)] Occurs for each Workflow installed (except Things) Edit: Looks like typo's! You have changed to using "download_url" instead of "download_uri"
  11. Kind of progress again - Things is now properly listed (Yay!), but I've lost all of the other workflows
  12. Yup - no problem: { "version": 2.13, "download_url": "http://alfred.daniel.sh/Workflows/Things.alfredworkflow", "description": "Faster, clearer results; tags, dates fixed; more Unicode fixes." }
  13. Yes - I have a bunch of entries like this: [com.danielsh.alfred.alleyoop: Things failed (2013-04-05-10:14:47)] But that is all - nothing to say why there was a failure
  14. Brilliant - that's Issue #1 fixed so many thanks for this. Issue #2: As reported, the Things Workflow still doesn't appear to AlleyOop for me. There was an update to AlleyOop (v2.0 - Security Fixes) that I just installed, but the issues remains afterwards For completeness, the update.json file now shows this: { "version": 2.13, "remote_json": "http://alfred.daniel.sh/Updates/Things.json" }
  • Create New...