# Rnote: a GTK4 vector sketching app for stylus users, and where it stops

> Rnote is a Rust and GTK4 drawing app for handwritten notes, PDF annotation and an infinite canvas. It installs as a Flatpak on Linux, an app bundle on macOS and an installer on Windows, and its file format is explicitly marked unstable.

**flxzt/rnote** — Sketch and take handwritten notes.

- Repository: https://github.com/flxzt/rnote
- Website: https://rnote.flxzt.net
- Stars: 11,721 · Forks: 508
- Language: Rust
- License: GPL-3.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/flxzt-rnote

## What Rnote is for, and who it fits

Rnote is a vector drawing app for sketching, handwritten notes and annotating documents and pictures. The README names its audience directly: students, teachers and people who own a drawing tablet. That framing matters, because almost every design decision follows from it. The UI is adaptive so it works on a small screen and a large one, the input path is built around a pressure-sensitive stylus, and the canvas can be laid out as fixed pages, a continuous vertical strip, or infinite in every direction.

The document model is vector, not raster. Strokes, shapes and imported images live as objects you can select, move, rotate and resize after the fact. That is the difference between Rnote and a screenshot-and-scribble workflow: a lecture PDF imported into Rnote stays a PDF you can annotate, and the annotations stay editable rather than baked into pixels. Export supports SVG, PDF and Xopp for whole documents, and SVG, PNG and JPEG for pages and selections.

Who it is not for is equally clear from the README. Anyone on X11 is told the app does not work properly there, with stylus and touch input described as unreliable. Anyone who needs a frozen file format is warned that `.rnote` is unstable and may break compatibility between versions. Mobile is not mentioned at all in the installation section, which covers Linux, macOS and Windows only.

## How the Rust workspace is split, and what that means for the drawing pipeline

The repository is a Cargo workspace with four members: `crates/rnote-compose`, `crates/rnote-engine`, `crates/rnote-cli` and `crates/rnote-ui`. The dependency graph published in the workspace manifest points in one direction. `rnote-compose` and `rnote-engine` are workspace dependencies of the UI, and the CLI sits beside the UI rather than under it. So the geometry and document logic live in a crate that has no GTK dependency, and the GTK4 and libadwaita layer is a consumer of it.

That split is why a CLI exists at all. `rnote-cli` is described in the README as providing basic handling of `.rnote` files for automation, and it ships inside the Flatpak. A headless tool can only work if the document engine is separable from the UI, and the workspace layout is the evidence that it is.

The rendering stack is Cairo, with the `cairo-rs` dependency enabling the `png`, `svg` and `pdf` features. That lines up with the export formats the README lists. Stroke smoothing comes from `ink-stroke-modeler-rs`, geometry from `kurbo` and `geo`, and collision or hit-testing work from `parry2d-f64`. Two of the dependencies are pinned to a specific git revision rather than a crates.io release: `hayro` and `hayro-svg`, both at revision `56c62b2a25232d5407af8efe819c49ad46605979`. Pinning a git revision is a normal way to depend on a project that has not published a usable release, but it does mean a source build of Rnote is tied to a commit that may not exist forever.

The workspace declares `rust-version = "1.89"` and edition 2024, and the workspace version is `0.15.0` while the most recent release listed is v0.14.2. The version in `main` is therefore ahead of the last release, which is worth knowing if you are reading source rather than installing a build.

## Installing Rnote and taking a first note

The README gives one install path per platform. On Linux the official build is a Flatpak on Flathub, app id `com.github.flxzt.rnote`. On Windows the README points at the installer on the latest GitHub release, and also documents Winget:

```bash
winget install flxzt.rnote
```

On macOS the app is packaged as an app bundle by a third party, `dehesselle`, in a separate GitLab repository, with the latest release linked from the README. There is no Homebrew or MacPorts instruction in the README, so the bundle is the documented route.

Because the Flatpak is the reference Linux install, the CLI is reached through it rather than through a binary on your `PATH`. The README's example is:

```bash
flatpak run --command=rnote-cli com.github.flxzt.rnote help
```

Running that prints the CLI's own help, which is where the available subcommands are listed. The README does not enumerate them, so treat the help output as the source of truth rather than any command list you find elsewhere.

The README's downgrade procedure is the part most projects omit, and it exists precisely because the format is unstable. To see the available past versions on Flathub:

```bash
flatpak remote-info --log flathub com.github.flxzt.rnote
```

You pick a commit from the version you want and downgrade with `sudo flatpak update --commit=<commit-hash> com.github.flxzt.rnote`, then optionally pin it with `flatpak mask com.github.flxzt.rnote`. Unpinning is `flatpak mask --remove com.github.flxzt.rnote`, after which `flatpak update` returns you to the latest version.

For a source build, `BUILDING.md` and the `justfile` are the entry points. The `justfile` defines a `prerequisites` recipe that installs system packages on Fedora and on Debian or Ubuntu, covering `gtk4-devel` or `libgtk-4-dev`, `libadwaita-devel`, `meson`, `cmake` and `clang`, then installs Rust through rustup. The build folder defaults to `_mesonbuild`, which tells you Meson drives the build rather than Cargo alone.

## The limitations the README admits, and the one it does not

The Pitfalls section is unusually direct. X11 is unsupported, not merely deprioritized. The reasoning given is that upstream support for X11 in GTK4 and desktop environments will decline over time, so fixing X11-specific issues is no longer feasible. If you are on an X11 session, that is a hard boundary rather than a bug report you can wait out.

Drag and drop failing is a permissions problem, not a code problem. The README tells you to check that Rnote can access the source location in Flatseal. The related symptom is a header title showing a path like `/run/user/1000/../`, which means Rnote lacks permission for the directory it thinks the file is in. Both are Flatpak sandbox behaviour that any Flatpak user will recognize.

Stylus buttons and canvas panning failing usually means `libinput` and `libwacom` are missing or not loaded. And there is a class of stylus that sends an "Eraser Tool" event instead of a primary or secondary button event. The README names the lower button of the HP MPP2.0 Tilt pen and the back of the Microsoft Surface Pen as examples, and states that Rnote does not natively handle those events. The practical effect is that your shortcut mapping may appear inverted, with the upper button behaving as the lower one.

Palm rejection is the case where Rnote is honest about having no fix. Some devices reject palm input while the stylus hovers, which blocks other input events in parts of the screen. If your device has a left or right handed setting, the README says to set it correctly, and adds that Rnote cannot disable this behaviour.

The limitation the README does not address is the CLI's surface area. It says the CLI provides "basic handling" and points you at `help`. There is no documented scripting example, no exit-code table and no statement about which operations are non-destructive. If your plan is to batch-process a directory of `.rnote` files in CI, the README does not tell you whether that is safe, and the unstable format makes the question sharper.

## Rnote against Xournal++ and against a plain PDF annotator

The obvious comparison is Xournal++, and the difference is in the rendering model and the toolkit. Xournal++ is a C++ application built on GTK3, and it has a long history of X11 support. Rnote is Rust and GTK4, it targets Wayland, and it declares X11 unsupported. If your machine runs an X11 session and you depend on stylus input, Xournal++ is the tool that will work today and Rnote is the one that will not, by the project's own statement.

The second difference is the document model. Rnote is vector-based throughout, and its document layout is a setting rather than a fixed page stack. You can work on fixed pages, a continuous vertical scroll, or a canvas infinite in every direction. Xournal++ is organized around pages. Neither is better in the abstract, but the infinite canvas changes how you plan a document, and it is a poor fit if what you actually want is a stack of A4 pages to print.

The third axis is format interoperability. Rnote exports to Xopp, which is the Xournal++ format, so moving a document out of Rnote is possible. The reverse direction is not documented in the README. If you are choosing between them on the assumption that migration is symmetric, the README only supports one half of that assumption.

Against a general PDF annotator, the trade is different again. A PDF annotator gives you a stable file that any reader can open. Rnote gives you editable vector strokes and an unstable native format. If the output that matters to you is a PDF someone else will read, export from Rnote is the last step, not the working format.

## Licence, packaging and the cost of keeping up

Rnote is GPL-3.0-or-later, per the workspace manifest, and the repository carries a `LICENSE` file. The GPL matters in one specific way here: if you link Rnote's engine crates into your own application and distribute it, the copyleft terms apply to that distribution. Using the app to produce notes, or running the CLI over your own files, is not the same thing as incorporating the code. This is a description of the licence field, not legal advice; read the licence text if you plan to reuse the crates.

The maintenance picture from the repository data: the last push was on 2026-09-21, the repository is not archived, and the most recent release is v0.14.2 from 2026-05-01, preceded by v0.14.1 on 2026-04-13 and v0.14.0 on 2026-03-25. Releases are not frequent, and the workspace version in `main` is `0.15.0`, so there is unreleased work in the tree.

Upgrade cost is dominated by the format disclaimer rather than by packaging. The README states the file format is unstable and might change and break compatibility between versions. That is why the downgrade instructions exist and why `flatpak mask` is documented: pinning a version is the supported way to stay on a format your existing documents were written in. Budget for that. If you keep years of notes in `.rnote`, the export to PDF or SVG is your archive copy, and the native file is your working copy.

Source builds add a second cost. The `justfile` installs a system dependency set including GTK4 and libadwaita development packages, Meson and CMake, and the workspace pins two dependencies to a git revision. A source build is reproducible only as long as those revisions remain reachable.

## Conclusion

Adopt Rnote if you draw on a tablet under Wayland on Linux, or you want a Rust and GTK4 note app whose documents export to SVG, PDF and Xopp. Skip it if you need X11 stylus reliability, a stable on-disk format you can archive for years, or a mature mobile build. Before committing a semester of notes, verify two things: that your distribution's Flatpak gives Rnote access to the directories you drag files from, and that the .rnote format version matches the one your collaborators run, since the README states the format can change and break compatibility between versions.

## FAQ

### Is Rnote free to use?

Yes. The workspace manifest declares the licence as GPL-3.0-or-later, and the README links to Flathub, a macOS app bundle and a Windows installer without any paid tier. The README also links a Liberapay donation button, which is optional.

### What are the key differences between Rnote and Xournal++?

Rnote is written in Rust and GTK4 and states that X11 is unsupported, while Xournal++ is the older GTK3 application that still works on X11. Rnote is vector-based with document layouts that include fixed pages, a continuous vertical layout and an infinite canvas in every direction, and it can export to Xopp, the Xournal++ format.

### How do I install Rnote?

On Linux the official build is the Flatpak on Flathub with app id com.github.flxzt.rnote. On Windows you use the installer from the latest GitHub release, or run winget install flxzt.rnote. On macOS the README points to a third-party app bundle maintained by dehesselle.

### How do I install Rnote on Ubuntu?

The README's Linux instructions are the Flathub Flatpak, which works on Ubuntu, and there is no apt package documented. For a source build, the justfile's prerequisites recipe covers Debian and Ubuntu and installs libgtk-4-dev, libadwaita-1-dev, libasound2-dev and libappstream-dev along with Meson and CMake.

## Sources

- [flxzt/rnote on GitHub](https://github.com/flxzt/rnote)
- [License: GPL-3.0](https://github.com/flxzt/rnote/blob/main/LICENSE)
- [Project website](https://rnote.flxzt.net)
- [README](https://github.com/flxzt/rnote/blob/main/README.md)
- [Releases](https://github.com/flxzt/rnote/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/flxzt-rnote
