This was a quick one. The previous release of the app should have resolved an
annoying bug. In the very last commits, though, we kind of worsened it. So,
time for a quick hotfix release!
For some while, we had an issue with the app that on Android, on some devices,
no icon would be shown on the launcher screen. The last release was supposed to
bring a fix which remedies this. Unfortunately, after we indeed fixed that
problem, in one of the later merges the setting of the icon on Android was
completely turned off 😱
Fortunately, bringing back the icon is a matter of setting some property
in an XML file and building and pushing out new versions. 😉
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).
Yes, it seems to become a kind of bad habit to release OpenTodoList behind
schedule, but this time, we have a good excuse (some traveling in parallel, so
this is the first version of the app that is effectively released from outside
Europe 😉).
So, what’s new this time? Effectively, this is mostly a bug crushing release, ridding
us of some long running deficiencies and hence, making the app way more
useful - especially on mobile devices. Curious? Then let’s go!
OpenTodoList allows adding images as library items for a long while. Nearly
equivalently long, you could add files as attachments to items. Clicking on an
image or an attachment basically just opens it in a suitable app.
But… this in fact only worked properly on Desktop systems. On mobile systems,
due to the sandboxing that is done, this didn’t work so easily. Well… until
now! Clicking an image or attachment now opens it in a preview and also allows
sharing it to other apps. 🎉
Back to one of our favorite topics: WebDAV. It is OpenTodoList’s main protocol
used to talk to backend servers for synchronization (the NextCloud and ownCloud
backends are basically special WebDAV ones).
Unfortunately, not all WebDAV servers play nicely and implement the full WebDAV
protocol. The app implements some workarounds for at least some of the
shortcomings servers might have. And this is where the trouble starts… some of
the workarounds cause the app to generate additional traffic on each sync. A
single sync typically does not consume too much data, but depending on the size
(or rather, age) of a library, if the background sync happens often enough,
the amount of transferred data can reach several hundred MBytes per month.
In this version, we - for this reason - reduce the frequency of the sync in the
background in case of a server with such issues is used. That way, the amount of
traffic generated should be in an acceptable range.
Another long standing request we finally managed to implement: The app is now
packaged as a Zip file for easy distribution of the app on Windows systems that
don’t support installation to system locations. 😎
One more nasty bug 🪲 that we fixed: On some Android devices, the app icon was
not properly shown. This was due to the format of the icon used - and should
be a thing of the past.
Last but not least, another cool new feature: You can now expand the tags in the
sidebar - this will show a list of library items belonging to this tag.
In addition, there is now a new option there per library, which shows all
items that have no tag assigned to them. This one can be expanded as well to
reveal top level items directly within the sidebar.
This feature makes it way quicker to jump between items directly without having
to load the contents of that (subset) of a library 🏎️
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).
While work on the next release of OpenTodoList continues, we’d still like to
push out another bugfix release to you. This mainly is important for users of
the Snap and AppImage editions of the app on Linux.
In the previous release of the app, we updated to a new version of the
underlying Qt toolkit the app is built upon.
Qt now requires OpenSSL v3 - however, we didn’t deploy this version of OpenSSL
with the app! In the Snap edition, this is fatal, because Snaps run in isolation
and cannot access any system libraries… But also the AppImage version of the
app (from which the Snap one is build) is affected! AppImages can in fact access
system libraries, but users that are on an older Linux distribution might not
yet have the new OpenSSL available 😱
We fix both of this by including the proper OpenSSL libraries with the app, so
access to secure servers should work again!
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).
today’s a special day for OpenTodoList - exactly 10 years ago, the first blog
post announced the availability of the first version of the app! 🎉
So… the best way to celebrate is to push out a new release, right? Joking
aside - there are some issues in the previous release’s Android build, that
we’d like to get sorted out by this. So, here is what changed:
Changelog
No Encrypted (HTTPS) Traffic Possible In Android Version Of The App
In 3.45.0, we updated the underlying Qt framework to a newer version. However,
this would have required a newer version of the OpenSSL library to be shipped
with the app as well on Android - which we missed. As a consequence, the app
started just fine, but was unable to do any communication over encrypted
channels. This affected both existing accounts as well as when one tried to
add new ones.
This release fixes this by adding the needed newer version of the OpenSSL
libraries to the APK.
As a little gimmick, this release also fixes the text in a label in the
recurrence editor. This is nothing big, of course, but it makes the user
interface more consistent, right? 😉
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).
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 😉
This is how OpenTodoList looked like 10 years ago
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!
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!
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.
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!
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).
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.
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 😉
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!
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.
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).
