Jump to content

phyllisstein

Member
 View Profile  See their activity

  • Posts

    366

  • Joined

  • Last visited

  • Days Won

    7

 Content Type 

Everything posted by phyllisstein

  1. phyllisstein
    Your screenshot is a bit too small for me to read, but it looks like it's working fine. Where are you seeing a problem?
  2. phyllisstein
    Alright, I've just uploaded a new version to http://alfred.daniel.sh/Workflows/OpenMetaTags.alfredworkflow that will hopefully correct the problem. If not, let me know.
  3. phyllisstein
    I'll give it some thought, but I don't think so; all the internal searching is done by tag, not by file. Could you check the workflow's folder for a file called "feedback.log" and let me know what it contains? Thanks.
  4. phyllisstein
    Unfortunately, the entry syntax is fixed by Things. Normally you're able to enter something like >+1 to indicate "one day from now," but a bug in Things 2.2 currently restricts you to using MM/DD/YYYY. Keep an eye on the release notes for upcoming versions; they'll reflect the change when this is fixed.
  5. phyllisstein
    CulturedCode support tells me that they found the bug today, but it just missed making it into a bugfix build they submitted to the App Store. It'll be in the next scheduled update, so keep an eye on their release notes. For now, it should work if you use >MM/DD/YYYY to set a due date. I'll update the original post accordingly.
  6. phyllisstein
    So it does. I don't know what the problem is; all I can say is that it's not the workflow, since issuing the command from AppleScript Editor crashes it just as certainly. I'll send their support an e-mail, and I suggest that anyone else who sees this do the same.
  7. phyllisstein
    Nice work! You might want to rename it to reflect the fact that it's adding comments, not tags, though; OpenMeta tags are a different animal than Spotlight comments, as you can see from my tagging workflow.
  8. phyllisstein
    Yeah; I have no doubt that the search API Apple exposes works differently from the search in iTunes itself. Among other things, the API requires that I make two requests for a basic keyword search: one for "items," and one for "artists," and so artist results will always be the second-place set, even when they're more relevant. It also just has a more general habit of returning crummier, less relevant results that I can't really account for: I've been over and over the API docs looking for a different way to ask it the question I want to ask without any luck. Consequently, this is the workflow of mine I use least often. *shrug*
  9. phyllisstein
    Great! Glad it was something dumb; always easier to fix that way. Enjoy!
  10. phyllisstein
    Strange, I can't seem to reproduce the error; even if I throw some parentheses into the task, nothing in the task syntax breaks on my end. I've just uploaded my working copy again; you might want to try grabbing it to make sure I didn't do something foolish like neglect to export the new version.
  11. phyllisstein
    Hm, what does feedback.log say?
  12. phyllisstein
    Looks like it was another issue with alp's fuzzy matching—the bracket was being interpreted as part of a regex, not as part of the literal string. Did a quick-and-dirty test and it seems to be working now: http://alfred.daniel.sh/Workflows/Things.alfredworkflow
  13. phyllisstein
    Sorry all, silly typo. Just tested http://alfred.daniel.sh/Workflows/Alleyoop.alfredworkflow and it seems to be working.
  14. phyllisstein
    It was actually the update-check for Alleyoop itself that was timing out, and so it's indeed my site. I believe that some of the workflows are hosted on Dropbox; a number are on Github; some are on personal sites.
  15. phyllisstein
    It looks like your connection is timing out. Unfortunately, there's not much I can do about that except catch the exception and skip the workflow that's timing out; that's no guarantee, I'm afraid, that it'll work on any of them. You can try with the updated version at http://alfred.daniel.sh/Workflows/Alleyoop.alfredworkflow though.
  16. phyllisstein
    It would be helpful if you could post the contents of "all.log" from the workflow's folder here so that I can get a better idea of what's going on.
  17. phyllisstein
    I made a couple of changes to get it running again; try http://alfred.daniel.sh/Workflows/iTunesStore.alfredworkflow International users will be pleased to know that they can now set the country whose iTunes/App Store is searched by modifying the file ~/Library/Application Support/Alfred 2/Workflow Data/com.danielsh.its/settings.json and including a key--value pair like this: { "country": "NL" } I've uploaded the old version to http://alfred.daniel.sh/Workflows/iTunesStore (Old).alfredworkflow, but I don't plan to support it or update it any further; it won't have feature parity and I can't drive myself nuts keeping two versions up-to-date.
  18. phyllisstein
    A small change to alp's fuzzy search module seems to have helped on my end; let me know how it works for you: http://alfred.daniel.sh/Workflows/Things.alfredworkflow
  19. phyllisstein
    Not to worry; nobody likes bugs. I think I've squashed at least some of them in the latest version, so let me know how it works for you. I'm afraid that since it's just a script filter, there's no way I can see to do it without adding three more separate scripts or supporting two versions at once, neither of which is hugely appealing. I've been trying to get it to behave like this since the beginning, so I'm more inclined to stick with this version. If the search works the way it's supposed to, I imagine that most people will want to go straight to purchasing an item; if it doesn't, opening a web browser is way more memory-hogging than iTunes or the App Store.
  20. phyllisstein
    Hah, thanks! So the best I can do for now is catch the error, log it, and continue on to the next workflow hoping that things are better the next time around; it won't just fail on you, but if you notice that some workflows are conspicuously missing then it'll make sense to check the debug.log file for errors. I take this to be a slight improvement, at least, till I can figure out why this module is breaking. Self-update or download here.
  21. phyllisstein
    Thanks for the log files. I poked around a bit on my own system and got a couple of errors with requests_cache, so hopefully that was causing your trouble, too; I'll try and figure out what the deal is. Sorry for the inconvenience.
  22. phyllisstein
    Can you tell me what comes up in the .log files in the workflow folder?
  23. phyllisstein
    Sorry it took me so long to get around to this, gang, but I wasn't getting e-mail updates from this thread for some reason. I've just posted a new version of the workflow that updates some of the backend stuff, hopefully making it a bit faster, adds a direct fallback search in the App Store and iTunes Store, searches for artists, and opens the links it returns in the pertinent Store directly rather than jumping to a Web page. You can download it here or, if you've downloaded it recently, update it through Alleyoop.
  24. phyllisstein
    Thanks, good catch! I just fixed it with a new update. Hopefully that'll settle things for a while.
  25. phyllisstein
    Right you are. I just pushed a new version, 2.51, that removes downloaded workflows from the cache, corrects an error with the cache, adds timestamps to the downloaded workflows, and bounces the Downloads stack when the download is complete. Available here or through Alleyoop.
×
×
  • Create New...