OpenTodoList 3.45.0 Has Been Released

Summer, sun and… a new release of OpenTodoList!

We hope most of you enjoy some free time outside, relaxing and getting away from all the stress we usually have around us. For us, we were a bit busy and hence accumulated a bit of delay for this release. And hey, it’s really a special release! You wonder why?

OpenTodoList is turning 10 years on the 25th of July! 🎉

10 years - in terms of software, this is really a lot. And looking back, it was quite a journey! OpenTodoList started as a project to discover the newly release QML tooling within the Qt framework at that time. Initially started with a skeuomorphic design, you wouldn’t recognize the app again nowadays. Cannot believe it? Here’s some examples 😉

We want to take the chance to say a big thank you to everyone supporting us and the app until here! Be it through feature requests, bug reports, donations or also lending us an ear when we had issues and difficulties - all of that kept the development of the app going. And we’re not getting tired of it; the issue tracker is well filled so chances will continue to come for quite a while.

Speaking of changes… you surely are curious what this release provides, aren’t you? So, let’s have a deeper look into that!

Changelog

rpdev/opentodolist#515: Recurring Sub-Tasks

OpenTodoList allows most items to have a due date. And on top, you can set recurrence patterns, such that an item repeats e.g. every week or every 15 days.

But, what happens with child items within such a recurring item? For example, if you set a todo list to recur, what is with the contained todos (and their sub-tasks)? The simple answer in the past was: Nothing!

The “parent” item would be scheduled again for another date, but the children would remain marked as done.

With this release, this changes - so when an item recurs, all of its child items will get reopened magically. This should make recurrence on complex item structures way more useful!

rpdev/opentodolist#622: Improved Recurrence Editor

Recurrence is a theme for this release. We also took the chance to refactor the recurrence editor a bit - it should be way easier to control now, especially on large screens you don’t have to aim at tiny icons anymore to trigger an action!

This might also serve as a blue print for some further refactoring of the user interface in other parts of the app.

rpdev/opentodolist#620: Fix - Recurrence Mode not always applied correctly

The usual bug fixing cannot be missed, of course! There was in fact a bug - in the recurrence editor, every second time one opened recurrence mode dialog, the dialog would jump between the actually selected mode and the default one.

While this was not critical (the mode was applied correctly, so no harm done), it still was annoying and hence we’re happy that this one got fixed!

rpdev/opentodolist#621: Prevent accidental marking of future items as done

When a recurring item is marked as done, it actually is not getting closed but OpenTodoList basically updates the next effective due date for it. But, what happens if you try to mark a future instance of an item as done?

In the past, OpenTodoList would simply have allowed you to do so, rescheduling the item even farther into the future. So, users might accidentally close items and schedule them for later! 😱

Good, that this release brings relief here! When an item is schedule for the future and not yet due in the current scheduling interval, the app will show a short warning and you have to explicitly agree to close that future instance of the item (which might - after all - still be a use case here and there).

rpdev/opentodolist#623: Semi automatic closing of items when all children are done

Todo lists contain todos. Todos in turn can have sub-tasks that further structure the work that needs to be done to get that item “completed”. But what happens once e.g. all sub-tasks within an item are closed?

Until now, the answer was a clear: Nothing.

Starting from this version on, the app will - once all items within a container are marked as done - display a short tooltip which you can tap to also close the parent item. Of course, if that container still shall remain “undone”, you can simply ignore this message, but it can speed up your daily workflow a bit where it fits.

rpdev/opentodolist#619: Remove no-translations workaround on Windows

Up to some techy stuff: We had to introduce a workaround that avoided Qt’s internal translations to be shipped with the app on Windows. That workaround could be removed in that release 😉

rpdev/opentodolist#586: Use of shared macOS runners to build the app

While not exactly user centric, this is an interesting one: GitLab, the platform where OpenTodoList is hosted and mainly developed, also provides us the resources for building the app for most platforms. However, that build platform is rather Linux centric - while one could add own runners to their projects there, GitLab itself didn’t provide anything beyond Linux for a long time.

Some time back that changed and they introduced shared macOS runners. So we decided to switch to these to build the app for both macOS as well as iOS.

The clear advantage: We can always build 🛠️

Sounds too technical? Well, until now we had a macBook sitting somewhere on which any build had to run. And if this hardware was not available, build pipelines would simply start to fail. Not ideal, right? This is a thing of the past now!

rpdev/opentodolist#585: Use of shared Windows runners to build the app

Going into the very same direction is this change: We also use the shared Windows runners for building the Windows version of OpenTodoList now. Here, the story is a bit different, though.

We were perfectly able to build the app from the Linux containers in GitLabs build farm. However, the underlying technique to get this done - using cross compilation from Linux to Windows - sometimes broke. This was also the reason why we worked on this story for this particular release: The Windows build once again broke, with us unable to workaround it (except with quite some effort).

As a result, we now natively build on Windows. This allows us to use the “vanilla” Qt binaries from the Qt Company - which should stabilize things a bit as well.

👉 Please note that due to this change, we had to drop support for Windows 32bit builds! This shouldn’t be a blocker for most users and we really hope that meanwhile most of you have a 64bit capable Windows installation in use. If not, feel free to open an issue so we can investigate how to work around this. However, we feel that with Linux having abandoned 32bit in most use cases as well, it is time to sunset this variant of the app for Windows as well.

rpdev/opentodolist#618: Better icon for saving of notes

Finally, a little but probably welcome change: If you edit the notes of an item, you probably realized the round button which can be used to finish editing the text, right? Previously, we had a rather strange icon in use there, which most people associated with a kind of download function. We used this release to improve there and pick an icon which better reflects the function of that button!

Downloads

• Please find the download links for major platforms on GitHub.
• For Android, the release is available via Google Play.
• For iOS, the release is available via the App Store.
• If you use snap, you can install the app from the snapcraft.io.
• If you use flatpak, you can install the app from Flathub.
• For Arch based Linux distributions, you can install the app from AUR.

Known Issues

There is a minor known regression with the Qt6 based build of the app when running on Linux with Wayland. Reordering items via drag and drop works, but you sometimes have to click somewhere (e.g. the tool bar) to re-enable hover for the items after such a drag and drop operation. This has been reported as a bug against Qt in their bugtracker. Usually, you can start the app passing it the -platform xcb option to force using X11/XWayland (which does not show the same symptoms).