Jump to content

ipaterson

Member
  • Posts

    52
  • Joined

  • Last visited

  • Days Won

    2

ipaterson last won the day on July 8 2017

ipaterson had the most liked content!

Recent Profile Visitors

848 profile views

ipaterson's Achievements

Member

Member (4/5)

6

Reputation

  1. Please post this to GitHub in case anyone else experiences this problem and can provide a working patch; I no longer use Wunderlist.
  2. 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.
  3. 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.
  4. @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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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
  10. 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.
  11. 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.
  12. Glad to hear it, I hope you enjoy the workflow.
  13. 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.
  14. 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!
×
×
  • Create New...