phyllisstein

Do let me know if you come up with anything; when I plug in "kindle salvatore," I just get that list of results without the fallback switch.

An overly aggressive length requirement for the query, I suspect. Try the latest version at http://alfred.daniel.sh/Workflows/KindleBookstore.alfredworkflow and if it doesn't work, please check the workflow's folder for a file called feedback.log and post its contents.

It's definitely something to do with a database collision, but the strange thing is that it's happening in the "action" script rather than the "feedback" script—the action shouldn't be affected by the repetition of your search. In any case, I've just pushed a new version that disables caching in the action script. I'm not sure that it'll solve the bigger problem of what happens to a script in process when it's derailed by a new Alfred instance, but it should fix the database troubles.

I'll try to think of a creative way to check the names, but it'll be tough. A lot of developers are doing things like adding version numbers to their exported filenames, which could potentially throw it off a bit. But I'll see if I can think of something.

Hm, in all honesty, I'm not sure what do to about the issue with reopening Alfred; it's unclear to me what effect starting a new Alfred instance has on processes that Alfred's spawned in the background, aside from "a not-very-nice one." I'll investigate it a bit, but that traceback info doesn't immediately suggest any leads. The error with Pocket is on the Pocket developer's end: if you look at his update.json file, it's actually just an unmodified copy of my Things update.json file that I assume he forgot to edit. As for the update-revenants, try running oop!—if it clears them up, then Alleyoop's cache was being overzealous; if not, then I suspect there's an error with the developers' update files.

Oh, dear! That's a major problem indeed. I'd like to try to reproduce it on my own system—can you remember a more specific example of the kind of syntax that's causing the error? I just tried "draft, queer,swc" without a problem, as well as "phamily wbc,shirley." It might also help to know the paths to the files you're trying to tag when this happens—if you'd like, you can PM or e-mail me (at d at daniel dot sh) with that info. But the first thing to do is see if anything is being logged. If you could open up Alfred's preferences, right-click on "OpenMeta Tags," click "Show in Finder," and paste in (or send me) the contents of any .log files in that folder, it'd be a big help.

The debug line means that the developer never updated his or her JSON to reflect the changes in Alleyoop 2; unfortunately, that's out of my hands. The fallback search was a consequence of a silly Python indentation error—the version I just uploaded should fix it.

alp has been updated to incorporate the changes to the workflow backend in v2.0.4. Any arguments with a newline character will now be enclosed in <arg></arg> tags rather than arg="" attributes. Additionally, there have been some changes to the Requests module: you must now explicitly call a download method to grab data from the server—the init method no longer does this for you. This makes it easier to flush the cache if need be.

The framework has been updated to reflect the changes to workflows in v2.0.4 of Alfred. In particular, arguments with newline characters will now be enclosed in <arg></arg> tags rather than in arg="" attributes. Hopefully there'll be some bigger changes soon—I've got some neat stuff coming down the pipe. This update is currently only available through Github, as it's not really a major revision.

Meanwhile, while Richard and I sort that out, I've updated Alleyoop to version 3. Thanks to Shawn's wise suggestion, it now makes its server requests in parallel threads rather than sequential, blocking requests; it's much faster, and hopefully more or less as reliable. Developers, please check your JSON carefully: some workflows are still throwing exceptions, which makes Alleyoop's code a hideous nest of try…except statements.

Have you made changes to your system Python installation? The PyObjC libraries that's importing ship standard on Mountain Lion.

I'm wildly reluctant to add settings, because I take most of the workflow's appeal to be in its simplicity: find a folder, type a note, done. However, the fact that "dtn My fancy note" was getting thrown out was an oversight and a regression on my part—it should have been sent to the global inbox, which it will be in the version just pushed to http://alfred.daniel.sh/Workflows/DEVONthinkNote.alfredworkflow and Alleyoop.

I've been using "Command Line Tool," under "Applications." It's linked to the Foundation framework by default, but you can add others as needed. Then, in your workflow, just use "Run Script" (or "Script Filter") options that invoke your program:

./MyAlfredWorkflow "{query}"

I've just pushed a couple of things to Github and I thought I'd give you guys a heads-up. First of all, some minor but vital updates to Alfred.framework to clean up a number of bugs concentrated in the fuzzy matching algorithm but scattered passim over the rest of it, and second of all, the source for an updated version of my DEVONthink Note workflow, refactored to make use of Alfred.framework's fuzzy matching and feedback systems.

Next up for Alfred.framework is a preferences system; but after that, I'm open to suggestions. What could the framework do that'd make you think, "Hey, cool!"?

I've just updated this workflow to version 2.0. Though I believe there are still some UTF-8 bugs to be worked out, it currently provides an example of how to use some of Alfred.framework's basic functionality, and so I wanted to get it out there. The updated version fuzzily searches through your groups as you type, only kicking into note mode when there are no matches. While it's searching, you can select a group and hit Return to navigate down into it.

Download the workflow here and check out the source on Github.

I'm glad it's working again! However, in addition to having very little PHP, I'm not especially interested in implementing something that would require users to engage in that level of dicking around with their personal configurations. Working with the standard features is about as far as I'm inclined to go.

This morning, I've corrected a bug in the bundle configuration that was preventing the framework from loading outside of XCode (d'oh!), added a method for generating feedback XML from an array of AWFeedbackItems, and added a method for parsing arguments to the workflow. I've also changed the methods for adding feedback items so that they take the NSNumber literals @YES and @NO with the normal list of arguments, rather than having to be specified separately as BOOLs. The README has been updated accordingly, and the version is now v0.2.

The networking code hasn't changed—I suspect that the workflow legitimately can't reach whatever site you'd previously configured it with. In which case you may have to delete the configuration file by hand: navigate to ~/Library/Application Support/Alfred 2/Workflow Data/ and delete the directory com.danielsh.alfred.yourlsstats, then enter the configuration command.

As for customizing the shortened URLs, unfortunately the Yourls API doesn't provide that functionality yet.

Aha, right you are. Well spotted. I've just uploaded a new version to http://alfred.daniel.sh/Workflows/YourlsStats.alfredworkflow that should fix the problem. The update is also available through Alleyoop.

Shouldn't be a problem: just enter the configuration string again with your new values and the workflow ought to update them.

Thanks! I don't just yet, unfortunately, but I'm probably going to refactor my DEVONthink Note workflow in the next couple of days. Which'll also involve making a lot of improvements to the framework, I predict, since even just glancing at the workflow I noticed a passel of things that were missing or implemented awkwardly. (In particular, there needs to be a way to send a mutable array of feedback objects to the output method and a way to parse arguments.)

I've also decided to upload the source to Github; some of alp's best features came from others, so I'm glad to have more eyes on it. See the original post for a link.

@Andrew: True enough. Consistency is important! Enough so, at least, that I can't think of a relevant principle that'd trump it.

@_mk_: I'm not sure what you had in mind. It looks like this now, just a list of colors; I suppose I could add a file item and figure out how to add a color to it… somehow….

Hey everyone! As tends to happen when I have a great deal of other, more pressing work to do, I've just spent a couple of days on what I think has the potential to become a neat little project. It's an Objective-C/Cocoa framework for creating Alfred workflows. Like alp for Python, it makes handling a couple of basic but super-annoying workflow tasks—like providing feedback XML and searching—simpler and faster, resulting in your spending less time and less code on the boilerplate stuff and more time making your workflow work (and flow). There's a great deal more information in the README at my Alfred site, but here are the features I've managed to put together in the past 24 hours or so:

• Fast feedback XML generation;
• fuzzy searching of data, modeled on alp.fuzzy_search();
• argument parsing;
• the typical methods for accessing cache, storage, and local folders;
• basic error logging.

If you're interested, I recommend you take a look at the README; but if you just want to get your hands dirty, you can download the latest version of the framework at http://alfred.daniel.sh/framework/Alfred-latest.zip . The source and zip- and tarballs of major releases are also available on Github.

Enjoy, and let me know if you have any trouble!

Great! I'm thrilled that it's working. Let me know if anything unexpectedly goes wrong, and enjoy!

Alright, now at http://alfred.daniel.sh/Workflows/OpenMetaTags.alfredworkflow and available through Alleyoop, a compiled version with the target set to 10.6 that you may have better luck with. It's also, much to my great pleasure, wicked fast, and I've added the option to label Finder the Finder selection with the keyword "label." Share and enjoy!

Hey there Andrew! I was just rewriting one of my workflows when I had a sudden thought about what could be a neat feedback feature. If it's doable, it might be a little extra interface sugar if a worker of flow could flag a feedback item as the one that's automatically selected. For example, I'm outputting a list of Finder flag colors, but would like to be able to imply that the file is already red. Rather than adding another informational item or something along those lines, it would be nifty if I could add something like default="yes" to the red item. I don't have any kind of sense of how complex that would wind up being, since I know Alfred always starts from the top of the results list, but thought I'd throw it out there.