Getting Things GNOME is a ten year old Python app that still expects you to build it

The README is a contributor guide, not a user manual

The first thing to understand about Getting Things GNOME is that its README opens by telling you what you are reading. It is the index of information intended for new contributors, beta testers, developers and packagers, and it points to the project's main software development and management hub for the rest. User-facing information, including how to install the stable release with pre-built packages, lives on the project website instead. The application itself is a personal tasks and TODO list organizer for the GNOME desktop, inspired by the Getting Things Done methodology, and it is designed with flexibility and adaptability in mind so that it can be used as more than just GTD software, tracking everything from small tasks to large projects. If you are arriving to install a task manager, you are arriving at the wrong document, and that mismatch is the first fact to internalise before choosing it.

The build is Meson plus GTK 4, and the dependency list is long

The development version is built with meson, and the stated requirements are meson 0.51.0 or newer, python3 3.8 or newer, python-caldav, pycairo, pygobject 3.20 or newer, lxml, itstool, gettext, GtkSourceView 4.0 or newer and libsecret, plus Introspection files and libraries for GLib, pango, gdk-pixbuf, GTK 3, GtkSourceView 4 and secret. The distribution packages cover most of that, and the project gives one line per family.

# On Fedora:
sudo dnf install meson ninja-build gettext itstool gtk4-devel gtksourceview5 libportal libsecret python3-gobject python3-cairo python3-lxml
# On Debian/Ubuntu:
sudo apt install meson ninja-build pkgconf gettext itstool libgtk-4-dev gir1.2-gtk-4.0 gir1.2-gtksource-5 gir1.2-xdp-1.0 gir1.2-secret-1 python3-gi python3-gi-cairo python3-lxml

Two entries in that list deserve attention. GTK 4 and GtkSourceView 5 are the development headers, and the introspection packages gir1.2-gtksource-5 and gir1.2-secret-1 are the Python binding side that pygobject needs, which is why a plain gtk4 install is not enough on Debian. libportal appears on the Fedora line only, and setproctitle is listed as an optional dependency for setting the process title when listing processes with ps and similar tools. The optional CalDAV client, caldav on PyPI or python3-caldav on Debian, Ubuntu and Fedora, is what enables the CalDAV synchronization backend.

Running the app means launching a script, not installing a binary

Once the dependencies are in place, you run the development version with a script in the repository root.

./launch.sh

The documentation is explicit that this is the safest way to run the git version because it does not touch your normal user data, which matters more than it sounds in a task manager where the data is the whole point. The script has a set of options for development work. ./launch.sh -? lists them. -d enables debug logs, and -w enables additional Python development mode behaviour such as deprecation warnings. -p prefix-prog prepends a program to the main gtg executable script, which is how you run under a debugger such as ./launch.sh -p 'python3 -m pudb' or under a profiler with ./launch.sh -p 'python3 -m cProfile -o gtg.prof'. The -s dataset option selects a named dataset stored in a tmp folder inside the working directory, creating a clean one if it does not exist, and two exist: bryce, an anonymized dataset with a fair number of tasks, and screenshots, a set of pre-made tasks for showing the application off. Anything after -- is passed to the gtg binary itself, so ./launch.sh -- --help shows the binary's own help.

The plugin system drags in LaTeX and PDF tooling

GTG has plugins, described as modules for extending the user interface, and synchronization services, described as modules for importing and exporting tasks from and to external services. Some of them have heavy dependencies, and the Export and print plugin is the clearest case. It needs python3-cheetah, pdflatex from the texlive-extra-utils package on Ubuntu and Debian, pdfjam from texlive-pdfjam on Fedora, and pdftk, now called pdftk-java in Ubuntu and no longer available in Fedora.

# On Ubuntu/Debian:
sudo apt install python3-cheetah pdftk-java texlive-extra-utils texlive-latex-base

That is a TeX installation and a PDF toolchain attached to a to-do list. The optional dependency notes also flag a testing problem that is worth knowing about before you file a bug: you currently also need the optional plugin dependencies, because the tests do not automatically skip them, and help is welcome to improve that. So a contributor without the LaTeX stack installed will see failures that are not related to the code they changed, and the project asks for a fix to that behaviour rather than tolerating it indefinitely. The CalDAV backend is the other optional piece with real consequences, since it is the route by which tasks sync to a calendar server.

Tests, linting and a Makefile that predates the current toolchain

The test entry points are visible in the repository. The Makefile has a tests target that runs ./run-tests, a check target that runs pep8 and pyflakes, and a lint target combining pyflakes and pep8. The pyflakes target runs the checker over GTG, tests, scripts and run-tests, and the pep8 target runs pycodestyle with a maximum line length of 100 and ignores E128 and all blank line errors, which the comment explains as ignoring E3 errors. The run-tests script sits at the top level, alongside a Makefile clean target that removes the tmp directory, editor backup files and __pycache__ directories. The test configuration lives in pyproject.toml, where pytest is configured with an import mode of append and a test path of tests. The extra packages for the suite are python3-pytest, python3-pycodestyle and python3-caldav on both Fedora and Ubuntu and Debian, with the caveat in the documentation that the list may be out of date. There is also a .pre-commit-config.yaml, a pylint.rc, a po/ directory for translations and a snap/ directory for packaging.

Version 0.6 is from 2022, and the work moved to the default branch

The release history is where a potential adopter has to slow down. Three tagged releases are listed: v0.4 with the title 0.4: You Are (Not) Done from 2020-07-07, v0.5 titled 0.5: You Can (Not) Improve Performance from 2021-04-06, and v0.6 titled 0.6: Shin Kido Senki GTG Wing: Endless Recursion from 2022-03-02. Each title is a joke in the same series, and none of them is recent. Against that, the last push to the master branch was on 2026-10-16, so the code is being changed even though the tags are not moving. The repository is not archived. The practical reading is that the default branch is where the current work lives and the tags describe a historic line, which means anyone installing from a package built on the tags is running code from 2022, and anyone running from a checkout is running code whose stability depends on the day. The website still lists the stable release with pre-built packages for users, and the contributing guide is pointed at for realistic expectations about feature requests, which suggests the project is candid about this state rather than hiding it.

Editorial conclusion

Getting Things GNOME suits Linux users who want a local task manager that keeps their data in files on their own disk and who are comfortable running a development checkout, since that is the state the project is in. It does not suit users who want a packaged stable release, because the newest tag is 0.6 from 2022-03-02, and it does not suit macOS or Windows users. Before adopting it, run ./launch.sh in a clone and confirm the sample datasets load, install the distribution packages for GTK 4 and GtkSourceView, and read the CONTRIBUTING.md expectations on feature requests before you file one.

Frequently asked questions

Official sources

1. getting-things-gnome/gtg on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases