ipaterson

Please post this to GitHub in case anyone else experiences this problem and can provide a working patch; I no longer use Wunderlist.

Since Alfred does not offer a print output for workflows this would probably never be implemented as a standalone feature. However, it may be reasonable to open a text editor with the titles of all tasks in a list (or a search, or on the due screen, etc) that you can then print or otherwise manipulate. Please post a feature request for this on GitHub with an example of how you would expect to interact with the workflow in order to get that type of output. That will also give others a chance to think about and thumbs-up the idea.

That's a very interesting idea. There is a lot of code involved in supporting those applications so I would like to know more about your use cases for this. Would you please post a feature request for this on GitHub with a few concrete examples of how you used this for the Reminders workflow and how it might work for Wunderlist? That will give others a chance to think about and thumbs-up the idea. This would be a bit tricky since the code to get text from the application is AppleScript and this workflow is written in python, but there is already some interaction in place with applescripts so it is not impossible. If people are interested I would need to begin by requesting Jack James, the author of the Reminders workflow, to publish the scripts as a standalone module to avoid copying them into or rewriting them for the Wunderlist workflow.

@willgill and @Albert S, thanks for the kind words and happy tasking. If you have any problems or suggestions please report them on the GitHub project page.

Version 0.6.0 has been released with many new features! Just over 60 of you helped to test out the preview releases for this version over the past 6 months. I appreciate all of the feedback and bug reports and hope that you have enjoyed using the workflow. I rely on it every day and even more heavily now with the addition of task searching and completion. Changes since 0.5.4 New command format In 0.5.4, commands were in the format wl:pref. The colon was required and the entire command had to be spelled out. The old format still works but the workflow now uses a hyphen rather than a colon to facilitate going back to the main screen with alt+delete which stops at the hyphen. Commands also operate on partial matches, so rather than typing wl-upcoming or selectingUpcoming on the welcome screen you can type as little as wl-up or even wlu. Search and browse tasksThe workflow now syncs all of your Wunderlist tasks, allowing them to be searched and browsed. The Due and Upcoming screens allow you to find tasks based on due date and the Search screen can be used to search across all lists or browse individual lists and hashtags. You will occasionally notice a delay when visiting the wl-due and wl-upcoming screens because the workflow syncs before showing the results. Unfortunately the Wunderlist API has become very slow so even a single request to check whether the root revision has changed takes over half a second. Otherwise the sync has been massively optimized to ensure that it does not take much longer to sync all of your tasks than it did in previous versions to sync just your lists. Complete tasksThe search and browse screens provide access to individual tasks. You can complete a task, delete it, or view the full task in the Wunderlist desktop app. Other changes #103 Default list preference: choose a list other than Inbox as your default or default to the most recently used list Notifications when the first sync is complete or when the due/upcoming screen is waiting on a sync The database schema has been updated so your cached data will be discarded and a full sync initiated the first time you run the workflow #109 Standalone _wl-reset and _wl-full-reset commands for debugging Fixed incorrect display of the reminder date #111 Space after wl for entering a task is now optional since it was weird in hotkey to have to type a space #127 Fixes an error for Australian users when entering a task with a reminder Changes since 0.6.0-beta.6 #130 Removed "Let's discuss this screen" prompts #95 List title is now matched in addition to the task title when searching Reversed search result order to avoid showing completed tasks first Small performance improvements Bug fixesNumber of times overdue was not displayed Number of times overdue, once displayed, did not consider the recurrence count (e.g. 3 months calculated as 1 month) Reminders were displayed with the due date and reminder time in some cases rather than the reminder date Was not possible to browse lists that are substrings of other lists (e.g. wl-search work:would show the Work and Workouts lists, now shows tasks for Work) Alfred CompatibilityVersion 0.6.0 is compatible with Alfred 2 and 3. Alfred 2 will continue to be supported at least through the next major release. There are some Alfred 3 features that would make task completion and editing more convenient so I will need to evaluate whether I can take advantage of those or not and whether it would still be necessary at that time to support Alfred 2.

az566, which version of the workflow do you have? I recommend first making sure that you have the latest version, which is available here, then try signing out and back in through the preferences screen.

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.

Thanks, Andrew!

I'm not keen on changing the extension in GitHub releases if the file won't be executable without renaming for those who download it directly. I would rather see a solution that requires developers who are concerned about the transition to do a little extra work on their releases (e.g. adding a second binary or using a different tag format would both stop invalidate the release in old versions of Alfred-Workflow). If an alternate file extension is not going to happen the decision about how to approach the problem will be largely based on balancing developer effort (both yours and workflow developers) and mitigating the discontentment of users who choose not to pay for the Alfred 3 upgrade. Such a solution would be very specific to Alfred-Workflow rather than something nicely standardized across all workflow distribution channels so we should continue this part of the discussion on GitHub.

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 workflowsFor 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.

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.

Glad to hear it, I hope you enjoy the workflow.

Oh right, Packal. I forgot that Packal is not capable of following GitHub releases (or keeping track of how many times the workflow is downloaded). Please download from GitHub here.

Okay I see. After the first time Wunderlist asks you to log in, it does not show the authorization screen again if you are still logged in. There should be a parameter that I can set to make sure it always asks you to log in or choose your account (at least there is with Google login). The message you are seeing most likely means that the workflow was not able to start the server that listens for that code from Wunderlist. There could be a few reasons why it was not able to do that, but I have tried debugging that with other users in the past and it takes too much time for a feature that is never used again after you log in. It may be that the port is already in use or security settings are blocking the workflow from listening for the auth code. Anyway, I released an update to address this. After downloading 0.5.2 you should be able to paste the localhost URL into Alfred in order to log in. Enjoy!

Let's try to figure out what is going on here, can you first let me know at which step you see this "No data received" error and whether it is displayed in Alfred, the browser, or an error console? Click Please log in in the workflow Browser opens with Wunderlist authorization screen Log in to Wunderlist Wunderlist redirects the browser to http://localhost:6200with login info Workflow handles that browser request and logs you in Also thanks for reporting the spurious update message, that is odd...

@leetheadverb, I'm not quite sure what you're asking. Are you using the version of the workflow posted in this thread? It's very outdated now, the workflow has been rewritten due to two circumstances: OS X Yosemite completely broke the version that interacted with Wunderlist.app Wunderlist finally released a public API The new version is still in beta testing but it is much better than the previous version. "wl Oil change next Friday repeat every 3 months" sets up a task called "Oil change" due the following Friday and recurring seasonally. Of course, just shortly after I opened up the beta Wunderlist released their own update with natural language dates Perhaps your questions about Alfred for Trello would be better answered via that project's github issues.

Yeah I do think that features like that would be woefully underused. Worth polling your userbase on github in the v2 thread? We should probably start a new thread here if you want to discuss specifics with regard to workflows. For the calculator formatting, I meant that OSX still had spaces and commas in my system settings despite switching back to en_US, nothing was stuck in Alfred. It reset to US format when I made the decimals change manually in OSX prefs.

On a related note that might speak to user expectation, I noticed that the Alfred calculator respects my numeric separator settings. These settings must have been set when I changed to the fr_CA locale yesterday. Despite switching back to en_US the OS didn't revert my number formatting, so I was a bit surprised when I tried to use the calculator. Here is a simple example when my system was set to spaces for thousands separators (here we see "." instead of a space but I think that is common), and commas for decimals: None of the LANG/LC_* variables would have reflected this preference (they're en_US). Rather, the separators setting is stored in the AppleICUNumberSymbols global default. Ultimately it would be pretty tough for a workflow to always do the right thing. A guide on localization and helper methods from the various workflow libraries would be awesome for workflows that want/need to embrace international users without manually tiptoeing around all of these gotchas. I agree with Dean that Alfred's place is to ensure that the required encodings work with as minimal change to previous localization behavior as possible.

Well, PHP seems to follow a similar pattern of opt-in localization like Python. Unlike Python, in your example the locale does affect basic number formatting as documented (use %F to avoid localization): > LC_NUMERIC=de_DE.UTF-8 php -r "printf('%f', 123.456);" 123.456 > LC_NUMERIC=de_DE.UTF-8 php -r "setlocale(LC_NUMERIC, '');printf('%f', 123.456);" 123,456 However that does not seem to be global as some other common functions expose parameters that you have to set in order to emulate locales. Folks recommend using localeconv() to figure out the correct values for the decimal and thousands separators. Seems PHP 5 has a class to handle number formatting in a less ridiculous way. > LC_NUMERIC=de_DE.UTF-8 php -r "print number_format(123456);" 123,456 > LC_NUMERIC=de_DE.UTF-8 php -r "setlocale(LC_NUMERIC, '');print number_format(123456);" 123,456 > php -r "print number_format(123456,2,',','.');" 123.456,00

Those are tough to answer definitively, here's a try: Yes, but I would hope that in most cases this would positively affect workflows by improving the ability to localize, though there are also cases to the contrary. For example, if someone used %A in a strftime format to get the day of the week name, then operated on that name under the assumption that it would be English. Not every language and country combination works, see below We would have to figure out whether en_US was always the default locale (whether it came from this setting or elsewhere) in previous versions of Alfred. I'm not sure how much is done with the locale by widely-used native python modules – datetime springs to mind as a fairly obvious way to test locales since it supports locale-specific date representations. The locale can affect sorting, regular expressions, and other operations but in most cases I believe that locale-sensitive operations are opt-in (e.g. must use the re.LOCALE flag or must load the locale explicitly by type). Another question for Dean and anyone else more familiar with these things: since LC_CTYPE is only one of several variables that control localization, is it better to set the higher-level LANG variable? It seems that the system default is to set LANG, allowing overrides for each type if necessary. Python will take LC_ALL, otherwise LC_CTYPE, otherwise LANG as the default locale. Note that LC_ALL takes precedence over all the LC_* so we definitely don't want to set that. The other locales are ignored by default unless loaded explicitly by locale.setlocale(locale.LC_*, ''); where the blank string signals python to load the setting from the environment. For example, > LANG=en_US.UTF-8 LC_TIME=es_ES.UTF-8 python -c "import locale;from datetime import datetime;print datetime.now().strftime('%A');locale.setlocale(locale.LC_TIME, '');print datetime.now().strftime('%A')" Wednesday miércoles In this case, even setting LANG or LC_CTYPE to es_ES.UTF-8 still results in English for the first date format. It seems that workflow authors have to explicitly opt-in to non-English localization in Python. This is just the datetime module, other things could operate differently. I doubt the same opt-in policy holds true in all other languages. Finally, using printenv in a fresh terminal I noticed that some settings in the Language & Region pane cause OS X to set strange environment variables. For example, select English as the language, Canada as the country, then in advanced options choose French as the number and date format. One might expect to see LANG=en_CA and LC_TIME=fr_CA (along with LC_NUMERIC, etc), but instead OS X sets LANG=fr_CA. The AppleLanguages global default still shows en as the preferred language for text but there is no environment variable corresponding to that. Another example is English as the language, United States as the country, and Spanish as the number and date format language. While we would expect LANG=es_US following the behavior of the previous example, the only environment variable set is LC_CTYPE=UTF-8. Ouch, that's the one that bit Alfred in 2.7. The AppleLocale global default shows es_US. I think that speaks to your second question, some locale combinations are not supported and it is possible for real users to configure their systems in that way. Unfortunately a bad combination like es_US will also break stuff in Python: > LC_CTYPE=es_US.UTF-8 python -c "import locale;locale.setlocale(locale.LC_CTYPE,'')" Traceback (most recent call last): File "<string>", line 1, in <module> File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py", line 547, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting

I think the intention of setting LC_CTYPE=UTF-8 was great, but unfortunately the flag value must also include a locale (e.g. en_US.UTF-8). Otherwise if the value can't be parsed, python will crash at locale.getdefaultlocale(). Andrew reverted that change in 2.7.1 but I would like to discuss whether it would be possible to set LC_CTYPE including the system locale. My temporary workaround to fix the workflow in 2.7 was export LC_CTYPE="$(defaults read -g AppleLocale).UTF-8" where the AppleLocale setting is a string value formatted like en_US. Technically the user could set different formats for each of the LC_* environment variables, though I'm not sure how common it would be since only a few changes are possible in Language & Region. I have a bug report regarding unicode strings in XML output that could benefit from some follow-up testing. Since the current version of the workflow still includes the workaround above I will see whether the user is still having trouble after UTF-8 is specified. Will let you know if this fixes that problem.

Well done, in 2.7.1 the workflow is working again. I will follow up on the original discussion with some further thoughts.

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.

The next version of the workflow is ready to test. If anyone sees this and has a chance to try it out, version 0.3 should be faster to add tasks and lists and hopefully most of the common bugs have been fixed. New features have been held off for 0.4 due to the growing number of people that had issues with the current version 0.2, so this will have the same features that you are accustomed to. Download here and let me know how it works for you! This testing version will update to 0.3 when released if you use a workflow manager to keep up-to-date. If you are a developer and want to contribute or run through a series of semi-automated tests, checkout the develop branch then read the testing instructions. In a nutshell, ./run_tests.sh Please post any new issues to github or reply to the outstanding issues if you're experiencing the same. It's a lot easier to troubleshoot there than in the Alfred forums!