deanishe

Much appreciated They're some pretty cool workflows you've written there. May I suggest you consider including the library (and info.plist, icon.png etc.) in your repos. That way, if someone downloads or forks the repo, they have a working workflow.

Oops! My bad Out of interest, in what way would the "standard" version break the workflow? Is that just down to the lacking update functionality?

Important Message There is a pretty serious bug in all versions of the library previous to 1.8.6 (the current version). If a user has non-ASCII characters anywhere in the path to where his/her workflows are installed, the library will fail. If you've released a workflow based on Alfred-Workflow, please update it to use at least version 1.8.6 of the library. My sincere apologies to the users and developers this has affected.

That's 100% my fault: the problem is in a library that I wrote, which this workflow uses. I released a new version about 20 minutes ago that fixes this problem. I'm sure Fabio will update his workflow very soon to fix my error, but if you really can't wait, download the updated library from here, extract the zip file, and replace the workflow subdirectory in the Gmail workflow with the one from the zip file. That should fix the problem.

Yeah. When I started the workflow, that was basically the objective. I wanted to create a super-cool search-all-the-engines! auto-suggest workflow, but it quickly became apparent that it wasn't a particularly viable idea Still, I think it's turned out okay. The next step is, hopefully, to make it configurable without having to mess around with the workflow itself, much like Fuzzy Folders works. It annoys the hell out of me having to reconfigure the bleeder to my own purposes after every new release The major hurdle is being able to figure out exactly what languages/regions are available for each search engine. I suppose I could add what I'm aware of by default but still allow users to specify different languages/regions.

That's not an error. I don't know why Alfred is reporting it as such. There seems to be a regression in Alfred's debugger.

I tried that. It doesn't work. The first problem is that you don't get any results till all the web queries finish, so the speed of the workflow is restricted to that of your slowest search engine, and some are a lot faster than others. Secondly, you end up with lots of duplicate results. Either you strip out the duplicates, so you only have results from one search engine, which largely defeats the purpose of combining multiple search engines' results, or you have 10 results that are all the same, just from different places, which isn't very helpful. Thirdly, one of my main motivations was to enable users to search in different languages easily. And by that I mean multiple languages per user. As some search engines are set up by region and others by language, it's not really feasible to combine the results in a meaningful way (pass "uk" to Google or Wikipedia and you get Ukrainian results, pass "uk" to Amazon or Yahoo! and you get results from their British sites).

Yes, it is. I'll try to get that added over the weekend. Really busy with work at the moment

Updated to version 1.4 to fix an incorrect URL for Google Maps search. Thanks to Vítor for finding and fixing the bug.

Wanna buy a Title Case Server? I can get you a super deal on one!

Overcoming massive technical hurdles is sometimes necessary, but nobody's going to care if they're on a road to nowhere…

If by "ridiculously complex" you mean "comprising a ridiculous number of trivial steps", yes.

Wrong way to look at it, tbh. What makes a workflow great is implementing a good idea in a very useable way. It needn't be complex to implement. I dare say, what sets the best software apart from the mediocre is the amount of thought that went into it, not the feats of software engineering…

This is a bug in the underlying library. See here for details/progress. I'm afraid I had to move the updater to a different branch while I get this fixed, Fabio. Sorry

Confirmed as a bug in the library. I'll try to get that fixed by tomorrow. The fix is simple enough; creating the tests to ensure it doesn't happen again is a different matter…

I think those confirmation dialogs are built in to the respective system functions, not Alfred. If you want to show a dialog, you should look at AppleScript.

That's pretty good for users. The cheatsheet is very handy. The developer docs on writing workflows, however, are lacking. In particular, the page documenting Script Filters (the complex bit) only contains a reference to this forum. There is no correct and exhaustive explanation of the XML format anywhere (the included example workflow is incomplete, as is the stickied thread on the forum). The two included example script filter workflows contain escaping bugs

You're welcome. Your post actually helped me find a bug in web.py, so thanks! FWIW, what I normally do is make sure everything is Unicode by starting the file with: # encoding: utf-8 from __future__ import unicode_literals u = 'This is a Unicode string' s = b'This is an encoded string' (Instead of using u"" for Unicode strings, you use b"" for encoded strings, so normal "" strings are Unicode.) And then when I have a library that returns encoded strings, like BeautifulSoup, I'm careful to decode the output as soon as possible. If you use wf.logger.debug('%r', obj) to log objects returned by functions, you'll see whether they're strings/Unicode in the log (%r calls repr() on the object).

I've got the code up and running, I think. This is from your first script using my library. First of all, remove any print statements or make sure they write to STDERR (see previous post). STDOUT is where Alfred reads the XML from, so anything else printed to STDOUT will break the XML. Secondly, the title, url and desc returned by parse_baidu_results() are all strings, not Unicode. You have to decode these yourself using .decode('utf-8') or wf.decode(): title = wf.decode(title.replace('<em>', '').replace('</em>', '')) wf.logger.debug(title) url = u'http:' + wf.decode(part1.a['href']) part2 = table.find('div', {'class': 'c-abstract'}) desc = wf.decode(part2.renderContents()) Working with strings and Unicode is a PITA in Python 2, unfortunately Finally, the URL you're sending retrieving the results from isn't really correct. It won't work with multi-word queries, as query isn't being url-quoted. Here's a simple way to do it (web.py will correctly encode and quote it for you): def request_baidu_search(query): url = u'http://www.baidu.com/s' r = web.get(url, {'wd': query}) Here's my full working code: # encoding: utf-8 from workflow import Workflow, ICON_WEB, web from BeautifulSoup import * import sys def request_baidu_search(query): url = u'http://www.baidu.com/s' r = web.get(url, {'wd': query}) r.raise_for_status() return parse_baidu_results(r.content) def parse_baidu_results(content): soup = BeautifulSoup(content) tables = soup.findAll('div', {'class': 'result c-container '}) results = [] for table in tables: part1 = table.find(attrs={'class': 't'}) title = part1.a.renderContents() title = wf.decode(title.replace('<em>', '').replace('</em>', '')) wf.logger.debug(title) url = u'http:' + wf.decode(part1.a['href']) part2 = table.find('div', {'class': 'c-abstract'}) desc = wf.decode(part2.renderContents()) results.append((title, url, desc)) return results def main(wf): query = wf.args[0] def wrapper(): return request_baidu_search(query) #results = wf.cached_data('results', wrapper, max_age=60) results = request_baidu_search(query) for result in results: wf.add_item( title=result[0], subtitle=result[1], arg=result[1], valid=True, icon=ICON_WEB) wf.send_feedback() if __name__ == '__main__': wf = Workflow() sys.exit(wf.run(main))

There's a print statement in parse_baidu_results(). That will break the XML output. Either use wf.logger.debug(title) (using my library) or print(title, file=sys.stderr). These two lines in both your scripts will have no effect: reload(sys) sys.setdefaultencoding('utf-8') sys.setdefaultencoding() only works if it's in one of Python's system-wide start-up, sitecustomize.py. Changing sitecustomize.py is a very bad idea as it will change the Python environment for all your Python scripts and your code will likely not work on anybody else's machine.

As David says, you can't reasonably create a list of all the things Alfred can do (it's too flexible), but there can and should be a manual describing how to do them (the interface is elegant, and tightly defined, but non-obvious). I'd argue for the creation of a wiki for Alfred documentation. This forum is a great Q&A resource for users and developers, but as noted above, it is far from ideal as a source of documentation or as a directory of workflows. Shawn's Packal has already solved the second problem, but the documentation for users and developers is a mess. As you note, there is no user manual (and it needn't be a big document—what Alfred can do is unrestricted, but how it does it is clearly defined, and that's the important information). Perhaps more importantly (this information is far more subject to change, and workflows are where much of Alfred's value comes from), there is no decent documentation available for developers. What little there is, is fragmented and often out of date. As most developers will tell you, one of the things most likely to send you running off looking for an alternative library/platform is bad documentation. While I know that if I update my workflow library and ask David to update the description in the relevant thread, he'll do it super-fast, he doesn't regularly verify whether the libraries/utilities listed there are up to date/still work/are still supported. Similarly, the "official" thread on Alfred's XML format is both long and incomplete. You can read all 5+ pages of it, but you still won't be fully informed of the ins-and-outs of the format because it hasn't been kept up to date. The Alfred team have not done a great job of documenting Alfred for users/workflow authors. Nevertheless, Alfred has a very active, knowledgeable and helpful community, and (given the less than stellar quality of "official" documentation so far) it makes sense for the Alfred team to leverage that community to help provide quality documentation. Alfred needs a wiki, sooner rather than later. Andrew, Vero and David can sit back and largely just moderate that, just as they do the forum, while Alfred's power users do most of the work of keeping it up to date (and experience shows they will). The way I see it, like with a workflow directory and auto-update mechanism (which Shawn stepped in to implement, when Andrew didn't), it's probably going to happen anyway. The question is probably whether the Alfred team want to have any influence over it or are happy to have it taken entirely out of their hands.

I assume you mean the workflow. Packal is a much better place to search for workflows than on the forum. Forums are great for many things, but they don't make good directories. FWIW, I wrote a workflow to search Packal if opening a browser window is too much effort, and Shawn (who wrote and runs Packal.org) has a particularly nifty workflow that can keep your workflows up to date.

Is this no good for you? Or did you want to write one yourself? I wrote a tutorial that describes how to do something similar with Pinboard.in posts. If you start off with that tutorial and replace the function that gets your Pinboard.in posts with the script you've found to get your Reading List items, you should be good to go.

You're conflating what can be done with how to do it. Alfred's use cases may be practically infinite, but its interface is both defined and finite. And it should be documented. Alfred's interface is pretty elegant, but it's also somewhat non-obvious, and a "handbook" a few pages long would cover all the essentials admirably. Explain what SHIFT and the arrow keys do, explain about TAB and modifiers keys, file system browsing and adding multiple files to the stack to action them. Okay. Then where is the explanation of how to set custom modifier subtexts in results? It isn't in that thread… I didn't say the thread was discontinued or abandoned, I said that a lot of the libraries/utilities in it have been discontinued/abandoned. Phyllisstein has explicitly stated that Alleyoop is abandonware. None of the libraries are actually broken AFAIK, but neither have any been updated in ~1 year apart from mine (and perhaps yours—there's no obvious way to tell), so they don't support arg as a tag or custom subtexts You've sticked and locked the thread, so it's impossible for anyone else to point out if one of the libraries no longer "Supports all Alfred 2 workflow features" (Alfredo) or when an author has explicitly abandoned the listed project, as with Alleyoop (and, I believe, Alp). That kinda puts the onus on you to keep it up to date. Exactly. Like I said: "one definitive, informative and up-to-date source". If stickied threads are the chosen form of documentation, so be it, but please keep them up to date by adding any relevant new information to the OP.

And that's exactly the reason there should be some kind of manual. It was over a year before I learnt that Alfred has a history of your searches, which is a pretty important feature, imo. Similarly, there's no proper documentation for workflow authors. What there is is spread across many forum threads. Instead of there being one definitive, informative and up-to-date source, you have to trawl through pages of posts in forum threads trying to work out what has changed since the original post. For example, the fact that arg can also be a tag instead of an attribute is 4 pages and 80 posts into the thread on feedback. The thread on libraries and helpers is also full of stuff that's essentially been discontinued or abandoned. This forum is a great resource for users and developers, but it is not a good replacement for a proper user manual, a developer reference or a directory of workflows.