iNotify-based conflict-preventing auto-reload prompt mechanism when GTG data file was modified from the outside

[nekohayo]

Historical context

From 2009 to 2020, GTG used to have a PID (process ID) based locking system, to avoid whatever data corruption/conflict danger may occur from running more than one instance of GTG at the same time. This also indirectly provided some safety for weirdos like me who use Unison to manually sync GTG across computers over SSH/SFTP (in fact, one of the reasons I don't use Syncthing for this is that I prefer to be able to check that no conflicting changes happen before syncing, and diff/correct them if I need to).

Sometime in the great migration from 0.3.x to 0.4, with the port to GtkApplication, the PID file approach was removed because it was no longer necessary to prevent more than one instance from running at the same time within the same user session on the computer... however this also incidentally removed my only safety mechanism for using GTG on multiple computers with file-based syncing.

Proposed new approach

A new idea suddenly struck me today. We could, like apps such as the various GNOME text editors (including Gedit, Apostrophe, etc. try them and see for yourself!), automatically detect external changes to the file and immediately prompt the user about it. This feature is built into the kernel and is called iNotify.

By watching the data file (and possibly config files and others?), as soon as GTG detects a change, it could show a dialog (or action infobar) to the user to let them know that the file was modified externally, and that they can either choose to reload now from the file, or to overwrite it with the current state of things. If reloading, then GTG would need of course to blank its UI and refresh it all with the data on disk. Overall, this is the simplest approach in terms of implementation.

A nicer UX, but much more complicated, is to offer a UI where the user can review and merge the changes to the tasks (i.e. created, deleted and modified tasks, maybe using Meld, which is also Python+GTK, to compare the modified tasks side-by-side), but that's way more complicated in terms of UI (and therefore code). Though arguably, if we have the code/UI for this, then this approach could be reused by @jaesivsm for conflicts handling in his CalDAV sync plugin implementation, who knows? 🤔

---

Python libraries exist for this, including pyinotify which is what Linux distros ship (in Fedora, in Debian, etc.), and it is not to be confused with the various other similar-sounding libraries like the "inotify" Python library or "inotify-simple", or others. When implementing this, one would need to also clearly explain which one we're using in the dependencies and README files, including under what names this might be found in distros (i.e. Debian-based vs others).