Getting Things GNOME! (GTG) is a personal tasks and TODO list items organizer for the GNOME desktop environment inspired by the Getting Things Done (GTD) methodology. GTG is designed with flexibility, adaptability, and ease of use in mind so it can be used as more than just GTD software. GTG is intended to help you track everything you need to do and need to know, from small tasks to large projects.

You are currently reading the index of the information intended for new contributors (beta testers, developers, packagers, etc.), found in the project's main software development and management hub.

See our website for the list of features and information intended for users (including how to install the stable release with pre-built packages). Except if you're here to report an issue – then you can just directly create an issue rather than continue reading.

Starting point for testers, bug reporters, and new contributors

• Keep reading below for basic instructions on how to get the development version of GTG running.
• See the CONTRIBUTING.md file to ensure you have realistic expectations regarding feature requests, and to learn how you can effectively help the project. Your involvement is what keeps this project moving forward, and we need you to play an active part in implementing desired improvements!
  • Explore the docs/contributors/ subfolder to see reference documentation for contributors, including coding/style conventions, how to deal with Git and submit patches, etc.

Setting up & running the development version

Getting the code

Execute this command to get the latest development code (if you don't have it already) and then move to that directory:

git clone https://github.com/getting-things-gnome/gtg.git && cd gtg

Later, when you want to update to the latest development version (assuming you are still in the "gtg" directory and did not make changes locally), you can do so with:

git pull --rebase

Dependencies

• meson (>= 0.51.0)
• python3 (>= 3.8)
• python-caldav
• pycairo
• pygobject (>= 3.20)
• lxml
• itstool
• gettext
• GtkSourceView (>= 4.0)
• libsecret
• Introspection (GIR) files and libraries from:
  • GLib
  • pango
  • gdk-pixbuf
  • GTK 3
  • GtkSourceView 4
  • secret

You can get most of those from your distribution packages:

# 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

Optional Dependencies

• setproctitle (to set the process title when listing processes with ps et al.)
• caldav (python3-caldav on Debian/Ubuntu and Fedora): required to enable the CalDAV synchronization backend.

Test dependencies

To run the current test suite, you need some additional packages (this list may be out of date):

# On Fedora:
sudo dnf install python3-pytest python3-pycodestyle python3-caldav
# On Ubuntu/Debian:
sudo apt install python3-pytest python3-pycodestyle python3-caldav

You currently also need the optional plugin dependencies, as the tests don't automatically skip them. (Help welcome improving that!)

Solving dependencies for plugins (optional)

There are additional plugins (modules for extending the user interface) and synchronization services (modules for importing/exporting tasks from/to external services) that might need additional packages to work correctly.

Dependencies for the "Export and print" plugin:

• python3-cheetah
• pdflatex (in the texlive-extra-utils package on Ubuntu and Debian)
• pdfjam (in the texlive-extra-utils package on Ubuntu and Debian, possibly in texlive-pdfjam on Fedora)
• pdftk (now called pdftk-java in Ubuntu, and no longer available in Fedora)

On Ubuntu and Debian you can install all that with:

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

Running the beast

In order to run the development/git version of GTG, you need to launch the debug.sh script There is a shortcut to it in the root directory where you downloaded the code, that you can execute simply with this command:

./launch.sh

This is the safest way to run the git version, as it does not touch your normal user data (see below).

You can use ./launch.sh -? to get a list of options useful for development you can append to the command, such as:

• -d to enable debug logs
• -w to enable additional python development stuff like deprecation warnings
• -p prefix-prog to prepend prefix-prog to the main gtg executable script, useful to run under a debugger: ./launch.sh -p 'python3 -m pudb' (with pudb) or a profiler: ./launch.sh -p 'python3 -m cProfile -o gtg.prof'
• -s dataset to use the dataset called dataset. It'll store it inside the tmp folder of the current working directory. If it doesn't exists, it'll create a new clean one. There are pre-made ones you can use by replacing dataset with one of the following:
  • bryce - An anonymized dataset with a fair number of tasks
  • screenshots - Pre-made tasks that can be used to show off GTG

If you somehow need to pass arguments directly to the gtg binary itself, anything after -- is passed to gtg directly. For example, use the following command to show the help for gtg itself:

./launch.sh -- --help

To examine the UI elements, you might be interested to use GTKs interactive debugger, that you can use by prepending GTK_DEBUG=interactive like:

GTK_DEBUG=interactive ./launch.sh

If there is any problem with meson (the build system) or anything else, try deleting the build folder first and try again: rm -rf .local_build. No data should be lost since it is just re-generateable build files.

Setting up a development environment

Now that you have installed all the dependencies and know how to run the tests, it's possible that you would like to make code changes and submit them for review.

We use pre-commit to run some checks that ensure that our codebase is clean and consistent.

Install it with pip install pre-commit, and install the pre-commit hooks with pre-commit install.

The checks will now run every time you make a commit, and fix files if necessary. It's generally a good idea to always run them, but you can also bypass them by running git commit --no-verify, if necessary.

The CI system runs the checks on each commit to master, and on each pull request. If you want to make sure they pass before opening your PR, you can run them locally with pre-commit run --all-files.

For more guidelines about contributing, see CONTRIBUTING.md.

Running the tests

Tests are run using pytest.

We first need some files to be pre-processed by meson, which is done by the following one-time step:

meson setup ./build
cd GTG/core/ && ln -s ../../build/GTG/core/info.py .

Then you can run the tests with pytest in the repository root.

"Where is my user data and config stored?"

It depends:

• If you are running a version installed system-wide (ex: a package provided by a Linux distribution), as GTG adheres to the [Freedesktop XDG Base Directories specification][basedir-spec], you will typically find it spread across:
  • ${XDG_DATA_HOME:-$HOME/.local/share}/gtg like ~/.local/share/gtg/
  • ${XDG_CONFIG_HOME:-$HOME/.config}/gtg like ~/.config/gtg/
  • ${XDG_CACHE_HOME:-$HOME/.cache}/gtg like ~/.cache/gtg/
• If you are running the Flatpak package version, those directories are all in ~/.var/app/org.gnome.GTG/ (or something similar)
• If you are running launch.sh (the launcher from the Git/development version), GTG doesn't touch your normal user data, it uses the tmp subdirectory in your current working directory (usually the repository root, the gtg folder). You can pass -s name to use a di