Errands is a GNOME todo app that syncs over CalDAV and ships as a Flatpak

Six features, and the list is the product

Errands describes itself as a todo application for those who prefer simplicity, and the README carries a GNOME Circle badge, which places it in the ecosystem of applications reviewed and blessed by the GNOME project. It is a Python application built on GTK4 and libadwaita.

The feature list is six items. You can add, remove, edit and complete tasks and sub-tasks. Tasks sync with Nextcloud or other CalDAV providers. There is support for multiple task lists. Each task can have an accent colour. And there is drag and drop support.

That is the whole scope, and the restraint is the argument. A task manager that is going to sit in a system tray next to a calendar and a mail client has a different job from a project management tool, and the design decisions follow from the job: colour as a quick visual tag, sub-tasks for the three step case, lists for separating contexts, and drag and drop for reordering without opening a menu.

For a reader deciding whether to adopt it, the honest test is whether the six lines cover your needs. If you want reminders, recurrence, priorities, subtask hierarchies beyond one level, or a project view, none of those are in the list, and the README does not describe them as coming later.

Sync runs through python-caldav, and only Nextcloud is guaranteed

The sync layer is not written in the project. Errands uses the python-caldav library to sync with Nextcloud Tasks and other CalDAV providers, which means the protocol handling, the calendar discovery and the scheduling of the todo entries are handled by an existing library rather than by this application.

The support statement is unusually clear, and it matters. The README says that for now, only Nextcloud is supported and known to work well, and that other providers may not work, pointing at the compatibility section of the python-caldav documentation for more information.

That is a narrow statement, and it is the main thing to weigh. Nextcloud exposes its Tasks app through a CalDAV collection, and the project has been developed against that arrangement, so a Nextcloud account is a path with evidence behind it. A different CalDAV host, a self hosted one, or a provider with a different CalDAV implementation, is a path where the client is untested territory. The failure mode is also worth anticipating: the app and the server disagree about a task, and the user has to work out which side is wrong.

The dependency list reinforces the picture. The application needs `python3-caldav`, and `gnome-online-accounts` is marked optional, which suggests that account discovery can also come from the desktop's own account system rather than only from credentials typed into the app.

The Flatpak on Flathub is the only supported version

Installation is one route. Errands is available as a Flatpak on Flathub, and the README states plainly that it is the only supported version.

For development there is a second path that avoids a packaging toolchain. The README describes building the Flatpak with GNOME Builder: install GNOME Builder from Flathub, click Clone Repository with the project URL as the URL, and then click the build button at the top. The repository listing confirms the packaging setup, with `manifest.json` and a `io.github.mrvladus.List.Devel.json` file for the development build.

The application code itself is a `meson.build` project with `meson_options.txt`, and the Python sources live in the `errands/` directory alongside `data/` for the interface resources, `po/` for translations and `build-aux/`. The Python tooling is configured in `pyproject.toml`, and the configuration there is small and specific: ruff is the linter with a set of excluded directories, and pyright is the type checker pointed at a local `.venv`.

[tool.ruff.lint]
ignore = ["F821"]

[tool.pyright]
venvPath = "."
venv = ".venv"

The single ruff rule that is switched off, F821, is the undefined name check, and switching it off in a project that also runs a type checker is a deliberate choice rather than an oversight. It is the kind of detail worth knowing before you contribute, because it tells you which failures the project will accept in continuous integration.

The dependency list is short, and packagers are asked to stay away

The packaging section carries a request that is unusual enough to quote. The README says the only officially supported format is flatpak on Flathub, and asks in those terms that you do not package it in other formats. If you do package it, the dependencies are listed so that your build has a chance of working.

The dependencies are `libadwaita >= 1.5`, `libsecret`, `libportal`, `gtksourceview5`, `PyGObject`, `python3-caldav` and `gnome-online-accounts` as an optional extra. Reading them tells you the shape of the application. `libadwaita` at version 1.5 or newer sets the interface floor, `libportal` is what a sandboxed application uses for portals such as opening files or talking to the desktop, `libsecret` is the keyring, and `gtksourceview5` is the text view used for editing task descriptions. `PyGObject` is the Python to GObject bridge that the whole stack sits on.

The version floor on libadwaita is the constraint to check if you are running an older GNOME release, since the application will not start against an earlier libadwaita. And the request to keep other formats off the distribution channels is a maintenance decision: one supported build means one dependency set to test, one translation flow and one place for users to find the app.

The Flatpak sandbox also shapes where the application can write, and the next section depends on that.

Logs live inside the sandbox, so bug reports come with a file

The contribution guide tells you how to report a bug, and the steps are specific because the application is sandboxed. First, make sure you are using the latest version from Flathub, since a fixed bug in a newer build makes the report moot. Then look at the log file, which is at `$HOME/.var/app/io.github.mrvladus.List/data/errands/log.txt`.

That path is the giveaway. The `.var/app` directory is where Flatpak keeps per application data, with the application identifier `io.github.mrvladus.List` naming the directory, and the log sits inside the application's own data directory under `errands`. A user can read it without any special tooling, which is the point: a reporter can paste the relevant part into an issue, and the steps in the README ask them to do exactly that, along with the steps to reproduce the problem if they can be described.

The repository listing shows the rest of the contributor surface. `TRANSLATIONS.md` is the guide for translating the application, matching the `po/` directory of translation files, and `DONATIONS.md` points to the funding route. `Errands.doap` is the desktop entry metadata file that software centres read, and there is a `LICENSE` file, with the project released under the MIT licence.

The project also follows the GNOME project Code of Conduct, which is the governance model the GNOME Circle badge implies and the one to expect for an application in that ecosystem.

The alternative is the Nextcloud web app, with the difference being where the data lives

There is a real alternative for the user this project targets, and it is the one the project syncs with. Nextcloud ships its own Tasks application, which stores the same CalDAV todo data in the same account. The difference in approach is where the work happens and where the data lives.

Nextcloud Tasks is a web application served by your own server, so the tasks live where the server is, the interface is the same one you use for files and calendar, and it works in any browser on any platform, including from a phone. Errands is a native client on your desktop, so the tasks live in the account but the interface is the one the desktop provides, built with libadwaita, following the GNOME look. It also means the app can be used offline for the parts of the task list that are already synced, and it can hold local state such as drag and drop ordering in a way a web app would have to round trip.

The project is explicit that other CalDAV providers may not work, which places the boundary of the alternative. If your task list already lives in a non-Nextcloud CalDAV server, the choice is between the server's own web interface and this client, and the README does not promise the client will work with it.

The alternative to Errands is therefore not another task manager, it is the provider's own client, and the decision is about whether you want a native desktop application or a browser tab.

Editorial conclusion

Errands suits a GNOME user who wants tasks and sub-tasks in a native app and a Nextcloud account to be the source of truth, and it does not suit someone on a non-GNOME desktop, someone who needs a CalDAV provider other than Nextcloud, or a packager who wants to ship their own build. Before you install it, check that your server is Nextcloud, since the README says only Nextcloud is known to work well and other providers may not work, and remember that the Flatpak on Flathub is the only supported version.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mrvladus/Errands on GitHub
4. README
5. Releases