ipaterson

Wunderlist Workflow for Alfred
Create tasks in Wunderlist more effortlessly than ever before with this Alfred workflow (requires Alfred 2 or 3 with Powerpack license).
Beginner and advanced approaches to adding a monthly repeating task beginning the following week:


Setup

Download here
After downloading, simply double-click to install the workflow in Alfred. Use the wl command in Alfred to activate the workflow, or assign a hotkey in Alfred preferences. The workflow will guide you through securely logging in to Wunderlist and will even let you know when an important update is available.

Documentation and Examples
My apologies, but it is not feasible to keep documentation in this thread in sync with the project page. 

Indeed there is and you can download it on GitHub in the latest 0.6.0-beta release. I am still taking small feature requests for this version and working through syncing problems, so please report any issues or suggestions on GitHub.
 
You can search tasks, browse by list or hashtag, and view what is due, then for any task you can mark it complete.

Hi jhonsvick, you might like the latest 0.6.0-beta workflow which has a few features that will help you out. Before I go into that I should mention that you can use portions of the list name rather than the whole name (depending on collisions with your other lists). For example, I always use "wl sh:milk" rather than typing out the full list name or selecting it from the displayed options.
 
In version 0.6.0, along with a wealth of new features related to searching and browsing your tasks there is a preference ("wl-pref") to default to the most recently used list. With this enabled, you could add the tasks with "wl sh:milk" "wl cheese" "wl cereal" and all would find their way to your Shopping list. I recently started using a hotkey with the workflow as well. Rather than typing Alt+Space to launch Alfred then wl to start the workflow I just double-tap the Alt key (go to the workflow screen in Alfred to set your own hotkey). Together these tweaks should greatly ease serial task entry as you described.

If anyone is looking for another way to digest my earlier post, here are a list of actions that would need to be taken to proceed with the file extension change if no better ideas come up:
 
For workflow developers
Be very clear about Alfred 2/3 compatibility when you share your workflows, especially if you have existing users on Alfred 2 Until you intend to drop support for Alfred 2 users, do not modify and export your workflow from Alfred 3, not even to make minor changes. Your workflow will likely no longer work in Alfred 2 (see below). Once you drop support for Alfred 2, export your workflows from Alfred 3 as .alfred3workflow files For Andrew in a patch release of Alfred 2
Inspect all workflows before installing to ensure object-level compatibility (see below), show a message and fail to install incompatible workflows For Andrew in the next release of Alfred 3
Add .alfred3workflow file association Export workflows with .alfred3workflow extension (or alfredworkflow3 as others have suggested) Inspect all workflows before installing to ensure object-level compatibility to guard against incompatibility with future changes in Alfred (see below), show a message and fail to install incompatible workflows Make the major version of Alfred 3 accessible in an environment variable (per deanishe) For Dean in the next release of Alfred-Workflow
Allow updates to the .alfred3workflow file extension but only if running Alfred 3  
I'm not familiar enough with how Packal works or what Shawn is planning to suggest anything on that front.
 
Also, based on a diff of the workflows from the earlier example of changing the keyword in the Should I watch this movie? example workflow, I tracked down the specific part of the info.plist that makes this incompatible with Alfred 2. It is not the addition or modification of config keys and values, nor the change from real to integer for positions, nor the addition of the version key. Instead, the only change that makes Alfred 2 show that the workflow is incompatible are the incremented object versions:
  <key>uid</key>   <string>F8C5D133-7C4D-44F2-845B-FAE1568A09E7</string>   <key>version</key> - <integer>0</integer> + <integer>1</integer>  
This completely makes sense; the configuration for the Open URL and Default Web Search actions in this workflow has been updated and Alfred 2 does not have support for these versions. The extra/changed keys in most cases will not matter because Alfred 2 does not know to look for them so they will be ignored. On the plus side, this suggests that determining whether a workflow is compatible may be exclusively a matter of looking for any objects with unsupported versions. Such a test would be independent of "Alfred 2 vs Alfred 3" since the component versioning is already built in. There are already some components on version 1 which means that during the course of Alfred 2 development there have been changes that would cause workflows in the latest Alfred 2 to be incompatible with certain older versions of Alfred 2. It is not unrealistic to believe that Alfred 3 will have similar changes before Alfred 4 is released and would therefore benefit from this type of object-level compatibility test logic. We can't deal with those at the file extension or download manager level, so Alfred needs to know not to install them.
 
Unfortunately, it also suggests that any component that has been updated in Alfred 3 will cause an incompatibility with Alfred 2 even if it is not edited directly as shown in my earlier example. I think that's pretty much every component that you can put in a workflow. Any change to the workflow causes all of its objects to be upgraded to Alfred 3's version of each respective component. This is why developers need to avoid editing workflows in Alfred 3 until they are ready to drop support for Alfred 2, and if you choose to ignore that warning be sure to test every release in Alfred 2. 
 
 
Oh and Dean, shields.io has a good widget for download counts of GitHub releases (and plenty other interesting badges), here's an example URL :
 
https://img.shields.io/github/downloads/idpaterson/alfred-wunderlist-workflow/0.6.0-beta.3/total.svg 

Context is very important to this decision, there are many contexts in which the ability to distinguish Alfred 2/3 support is important.
 
Installing an incompatible workflow in Alfred 2
There may be many different ways that Alfred 2 could be updated to detect and refuse to install an Alfred 3 workflow. The easiest but least robust approach is to do nothing; use a new file extension in Alfred 3 so that new workflows are not recognized by Alfred 2. Surely some Alfred-3-only workflows have already been released with .alfredworkflow but it is still early enough for this to be a passable, if disappointing, solution.
 
Preferably, inspect the extension before installing as mentioned by Vítor. Not everyone will want to use the new file extension (e.g. third-party update manager does not support the new extension yet) and some people will just remove the 3 and try to install the workflow anyway.
 
Developers accidentally dropping support for Alfred 2
Currently, making any change and then exporting the workflow from Alfred 3 results in a workflow that is incompatible with Alfred 2. Try it with the Should I watch this movie example workflow. Exported from Alfred 2, updated to use a different keyword in Alfred 3, exported in Alfred 3, then installed back to Alfred 2 yields an incompatible workflow. That is quite unfortunate, developers will accidentally drop support for Alfred 2 by making innocuous changes in Alfred 3. 
 
There may be a few approaches to that:
Avoid generating an incompatible workflow in Alfred 3 unless an incompatible feature is used – I assume this is much easier said than done Track whether a workflow was Alfred 2 compatible and warn before exporting – again, not sure how simple it is to determine whether a workflow was Alfred 2 compatible Export with the .alfred3workflow extension as a cue to the developer that the workflow will no longer work in Alfred 3 – not the best solution but probably the simplest  
Update managers that use GitHub releases
Deanishe's Alfred-Workflow checks the workflow's GitHub repository for updates with the option to notify the workflow user when an update is available and to download that update. This is a tremendous feature to have in a workflow and Alfred-Workflow even supports pre-release updates for workflows like mine that always have new features in active development for anyone willing to test. GitHub releases are based on master branch tags which, at least for the case of Alfred-Workflow, are semver version numbers. A higher version with a single .alfredworkflow binary means there is a release available.
 
Most importantly for me, the workflow cannot download the .alfredworkflow file to inspect whether it is compatible or not. GitHub tracks per-release download counts and these have become very important metrics to me since it is otherwise impossible to know how many people are using a workflow; downloading a workflow is not only wasteful of the end-user's bandwidth but would also inflate download counts. This leaves us with a distinction that can be modeled in the metadata for the GitHub release.
 
Options here include
a release tag naming convention – not preferable since straight semver is clear and simple something in the release name itself – a decent indication to the user but it will get old to always include marker text in the release title .alfred3workflow file extension – clear to the end-user and  start a new repository specifically for Alfred 3 – for workflows that do not rely on GitHub issues, stars, release download counts, etc this may be an option. Of those options, #1, #3, and #4 have the benefit of blocking workflows released with an older version of Alfred-Workflow from downloading an update meant for Alfred 3. Furthermore, the logic allows consecutive updates to Alfred 2 and Alfred 3 workflows which is beneficial for any workflow with a large number of Alfred 2 users and a backlog of bugs to fix.
 
I am not sure whether any other workflow libraries provide automatic updates.
 
Update managers that use static version files
Alleyoop allowed developers to publish a static JSON file with the latest version of the workflow. I am not sure whether alleyoop is still supported, but if so there would probably be a few ways to handle the version compatibility. It is more flexible than GitHub releases since the JSON could be modified as necessary to denote Alfred 3 compatibility.
 
End-users downloading workflow files from the forums or GitHub
Assuming that Alfred 2 will be updated to not install incompatible workflows, there is not a huge risk here. Upon downloading a workflow and installing I would see that it is not compatible with Alfred 2. Bummer, but after this happens a dozen times I would probably just pay for the upgrade to Alfred 3. This incompatibility would be obvious without even downloading the workflow if it has the .alfred3workflow extension.
 
Integrated workflow updates in Alfred
I stumbled across this note from Andrew in red about supporting secure workflow updates within Alfred. This may not still be the plan, but it would be great to support GitHub releases. Packal seems like another sensible place to look for updates. I suspect that this is a very challenging problem since integrating into Alfred involves considerable responsibility to protect the user and validate workflows. An integrated updater would need a way to distinguish 
 
Packal
I think that Packal has far fewer limitations; without any changes in Alfred Shawn could add a checkbox for developers to select "Alfred 3 only" on a release and show a corresponding message on the download page to warn users. Of course it might be nicer to be able to detect that automatically when the workflow is uploaded, and even nicer still to be able to offer a version of the workflow for both Alfred 2 and 3 at the same time. Since Packal keeps all submitted workflows in a GitHub repository the .alfred3workflow might be preferable here since Alfred 2 and Alfred 3 workflow binaries could both exist at once.
 
Packal updater
Again a lot of freedom since the appcast.xml could be updated to distinguish Alfred 3 compatibility. Since the updater is standalone rather than integrated into a workflow like the Alfred-Workflow updater it does not have the same problem of making sure old versions do not download Alfred 3 releases. Just publish an update to packal-updater that respects the new Alfred 3 distinction and 
 
 
I don't suspect that many people will continue to develop Alfred 2 versions of their workflow after they make changes in Alfred 3. For awhile we will see bug reports about workflows not installing in Alfred 2 simply because the developer does not realize that even minor changes in Alfred 3 can render the workflow incompatible with Alfred 2. Alfred 2 use will decline over time as users upgrade but since it is a paid upgrade for most we can assume that it will not be an abrupt transition.
 
Of all the options I prefer the alternate file extension since it seems to provide a workable solution in every case. It is not a particularly elegant solution and is not a complete solution in some of the contexts described above, but like Vítor said, it seems to be the most robust way to handle these various problems.
 
If the new file extension is supported in Alfred 3 I still recommend making it the default extension for workflows exported from Alfred 3. Like I said on GitHub, it provides a consistent visible indication to the developer, the end-user, and any software that is unable to inspect the binary contents that a workflow is only for Alfred 3.

So, the aim of setting LC_CTYPE (which was my idea, and setting it to UTF-8 was also my (bad) idea) was to get the various languages that pull encoding information from the environment to default to UTF-8 (which is what Alfred uses) instead of ASCII, which is causing many of the encoding problems.
 
That is to say, the intention is to change IO encoding to UTF-8 and nothing else.
 
I'm afraid I didn't test it with locale.getdefaultlocale() because it's basically useless in workflows (None, None) unless you call locale.setlocale() yourself first. It does work with sys.stdout.encoding and Py3's decoding magic. (The Python locale and encoding libraries seem to have very different ideas about what values are valid.)
 
I'm terribly sorry about providing a wrong value, but I still feel strongly that this is something that should be done if at all possible, as it will eliminate a lot of the encoding issues that have come up with Python, Ruby and Perl workflows.
 
The root issue is that Alfred uses UTF-8 but tells any POSIX-compliant languages by omission that IO is ASCII. As a result, encoding is basically always on full-manual and thus something that workflow developers need to worry about. In many cases, depending on language, your script works fine with bytestrings (pretty much everything is UTF-8 anyway), but utilities like pbcopy and pbpaste won't work properly unless IO encoding is explicitly set. Anything that tries to do text processing correctly (i.e. needs to know the encoding) requires you to set IO encoding (or do en-/decoding) manually because the implicit default is wrong.
 
As has been noted, using AppleLocale isn't a viable solution because it often has a value like en_IT if an Italian wants his/her apps to be in English (some of Apple's translations are weird). A further effect of this is that even if your language (i.e. not Python) doesn't choke on the value, you don't know if you should follow the en part or the IT part…
 
What I've done in the past is use AppleLanguages and "massage" the results into a useable locale. That was perfect for the situations I had, but would be a rotten general solution.
 
 
1. Depends on the workflow. Most aren't locale-aware (after all, there is no locale in Alfred). Changing the locale will change the way some languages behave, as ipaterson said. Any workflow that cares about locales probably has to set its own (perhaps Apple's own languages are aware of the OSX-level settings and don't use POSIX locales from env vars?)
 
2. No, there isn't such a locale. A locale is primarily the language
 
3. This is the important question (I think)!
 
Obviously, en_US (or any locale) is going to be wrong for many users. On the other hand, the locale is currently effectively C (the POSIX default if no locale is specified). So, we could reframe the question as "Is the C.UTF-8 locale available and useable?" If so, setting LANG=C.UTF-8 would fix the encoding and change nothing else.
 
From my tests, C.UTF-8 doesn't appear to work on OS X
 
However, as best as I can determine, there don't appear to be very many differences between C and en_US. At least, not as regards LC_CTYPE. Setting LANG to en_US might result in Fahrenheit popping up somewhere.
 
Would it be possible to try a beta with LC_CTYPE=en_US.UTF-8? That is, at least, definitely a valid value, and the closest one to the C locale that is assumed by default.
 
As far as Python goes, setting PYTHONIOENCODING=UTF-8 does the trick. On Py2 that just means that sys.stdout etc. have their encoding set to UTF-8 instead of ASCII, so print(u'ünicöde') works. On Py3, it means all the decoding magic Py3 does for you will work properly with Alfred's IO.
 
Regarding locales, timezones etc., Python is a bit rubbish. Its locale support is marginally useful (it's global), and it doesn't understand timezones. The tzinfo attribute in datetime is a placeholder that other libraries, like dateutil and pytz, populate.

Any python workflow using locale.getdefaultlocale() will crash in Alfred 2.7 due to an unhandled exception. Since the python docs do not suggest that it is even possible for an exception to be thrown from that function, I do not imagine anyone wrapped this in a try block.
 
I received some bug reports this weekend from some pre-release path folks who were seeing errors about unknown locale: UTF-8. I noticed in the release notes for the latest Alfred that the following change was made:
• Add LC_CTYPE=UTF-8 encoding to script environment
 
However, UTF-8 is not a valid value for this flag. Is this something that can be reverted or is there some case where it actually works? As a temporary workaround I was able to redefine LC_CTYPE in each of the bash scripts in the workflow, but hopefully that should not be necessary going forward.
export LC_CTYPE="$(defaults read -g AppleLocale).UTF-8"
 
Download a simple workflow that tests this bug. Type lcctype in alfred then action the result – it should show your current locale in large type but will instead fail with an exception.