mhoeher/opentodolist 3.45.0

on GitHub

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 below.
• 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).