RedNotebook keeps a searchable journal on your own disk, in plain text

A journal that stays in files you own

RedNotebook is a modern desktop journal that lets you format, tag and search your entries, and you can also add pictures, links and customizable templates, spell check your notes, and export to plain text, HTML, Latex or PDF. The topic list attached to the repository states the design intent more directly than the description does: cross-platform, desktop, diary, gtk, hashtags, journal, offline, python. The word offline is the load-bearing one. There is no account, no sync service and no companion web app in the description, and the export formats are the mechanism by which the journal stays yours. A journal that only exists inside an application is a journal you can lose, and a journal that exports to plain text and LaTeX is a set of files you can grep, diff and typeset later. For a researcher or a writer with a long memory and a low tolerance for vendor lock-in, that combination is the reason to look at this.

The stack is GTK and Python, which decides where it runs

The requirements section is explicit, and it reads as a set of constraints rather than a wish list. To run RedNotebook you need GTK 3.24, GtkSourceView 3.0 or newer, Python 3.8 or newer, PyYAML 3.10 or newer, WebKitGTK 2.16 or newer on Linux and macOS only, and PyEnchant 1.6 or newer for spell checking, which is explicitly marked optional. Installing it adds GNU gettext and Setuptools 60.0 or newer. The two version floors that matter in practice are the Python one and the WebKitGTK one, because the latter is the component most likely to be missing or too old on a long-lived distribution, and it is only needed on Linux and macOS. GtkSourceView is what gives the editor syntax highlighting, and the fact that RedNotebook does not bundle it but depends on it means the editor is a system component, not a shipped library, which is also why the readme points at a workflow file for installing dependencies per platform rather than a single script.

Running from source is one command per platform

The development entry point is deliberately small. After installing the dependencies, which the readme points at through the Linux and macOS and Windows workflow files, you start the application directly from the repository.

python3 rednotebook/journal.py

On Windows the command is the py launcher variant of the same script, and the two are listed side by side in the readme because that is the only platform difference in the start procedure. The other developer tasks are equally plain. You set up pre-commit hooks by installing pre-commit and running pre-commit install, and you run the test suite by installing tox and running tox. The repository carries a tox.ini for the test environments and a pyproject.toml with a setuptools build backend, and the project also keeps a Debian packaging directory and a Windows directory, which is the packaging evidence for the installers that the download page offers for Linux and Windows.

The build compiles translations, which is why gettext is a build dependency

The setup.py in the repository explains something the requirements list only hints at. RedNotebook is published under the GPLv2+ and the code bundles code released under LGPLv3+, so the resulting work is licensed under GPLv3+, and the detailed information sits in debian/copyright. The install script states plainly that to install RedNotebook you run pip install with the dot, and it defines a custom build_py command whose job is to call the project's own build_translations module on the po directory before the standard build runs. The comment in the file explains why the deprecated install command is used, since it provides the easiest way to install data files outside a Python package, and the translation files have to land in the share/locale directory under the prefix for the Glade file to pick them up. The project also credits the txt2tags team for its markup conversion tool and Dieter Verfaillie for the elib.intl module, which tells you the entry format is converted from a lightweight markup.

Formatting, tags and templates are the three things you do with it

The feature list in the description is short enough to enumerate, which is unusual for a journal application and suggests the tool is opinionated about the format. Formatting covers the entry text itself, and the credit to the txt2tags project points at a lightweight markup rather than a full editor format. Tags are the second axis, and the topic list names hashtags explicitly, so the tag vocabulary is a first class part of the data model rather than a metadata field bolted on for search. Templates are the third, and the description calls them customizable, which means the same skeleton for a weekly review or a reading note can be reused. The remaining capabilities are attachments, that is pictures and links, and spell check through the optional PyEnchant dependency. Search across all of it is what the application is for, and the presence of a separate search feature in the list, rather than it being implied by storage, tells you the journal is expected to grow large enough that finding things needs its own interface.

Export formats are chosen for where the writing goes next

The export list deserves more attention than it usually gets, because it is where a journal application either earns trust or does not. Plain text, HTML, Latex and PDF cover the four places a piece of writing usually ends up. Plain text is the archival format, and it is the one you can still read in twenty years without the application. HTML is the sharing format, for pasting into a blog or a ticket. LaTeX is the academic format, and it is the one that turns a journal into a typeset document without a word processor round trip. PDF is the fixed format for sending to someone. The readme does not describe the export in more detail than that, and it does not say whether exports are one file or many, or whether the search index is rebuilt after an import, so a user who cares about round tripping between formats will want to check the documentation site before committing to a workflow.

Where RedNotebook is the wrong choice

The first wrong case is a phone-first capture habit, because this is a desktop application and the readme describes no mobile or synchronised counterpart. Notes taken on a walk that never reach the desktop are notes you do not have, and the offline property that makes RedNotebook pleasant on a laptop is a liability on a phone. The second wrong case is a shared or collaborative journal, since the data is local and there is no service, so two people keeping a joint log would be merging files by hand. The third is a platform where GTK is not a reasonable dependency, which today means Windows without the stated installers or a locked-down managed environment, and the dependency list is not small. The fourth is a user who wants encrypted or synchronised storage without thinking about it, since nothing in the documentation describes an encryption story and a journal on a laptop is a file you have to protect yourself. The fifth is a note taker who expects a plugin ecosystem, because the readme documents the application and its dependencies rather than an extension mechanism, so the work of adding a new format or a new export target is yours.

Editorial conclusion

People who want a written record they can search years later, and who prefer their journal to live in files on their own machine rather than behind an account, are the people RedNotebook is for, and the export options to plain text, HTML, LaTeX and PDF are what make the data durable rather than locked in an application. It is the wrong choice for a note taker who wants a phone-first capture workflow, since this is a desktop application with a GTK toolchain, and it is the wrong choice for a team that needs shared or synchronised journals, because the journal is a local store rather than a service. Check three things before you install it: that you can satisfy the runtime requirements, which means GTK 3.24, GtkSourceView 3.0 or newer, Python 3.8 or newer, PyYAML 3.10 or newer and WebKitGTK 2.16 or newer on Linux and macOS, that you take the optional spell checking path only if you want it, since PyEnchant is marked optional, and that you read the licensing note, because the project is published under GPLv2+ but bundles LGPLv3+ code, which makes the resulting work GPLv3+. The licence for the project as distributed is GPL-2.0 with that stated caveat, the newest release is v2.43 from 2026-10-01, and the last push was on the same day.

Frequently asked questions

Official sources

1. jendrikseipp/rednotebook on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases