NormCap's Linux install recipe still carries a TODO, and every runtime dependency is an exact pin

The macOS path needs a manual override and a separate privacy grant

Of the three platforms, macOS is the one with two manual steps before the application runs. The file states you must allow the unsigned application on first start, through System Preferences, then Security & Privacy, then General, then Open anyway. The second step is separate: NormCap has to be allowed to take screenshots, and the README ties that requirement to issue 135. Two disk images are offered, one for x86/64 and one for arm64 for M1 machines, so the architecture split is handled but the trust prompt is not. Windows gets an msi installer and a portable zip, both x86_64, with no matching notes about signing.

The Linux Python recipe ships with a HIGH priority TODO still inside it

The block of shell commands for installing the Python package on Linux is the one place in the file that admits it is unfinished. After the dependency recipes and pip install normcap, the block contains the line `#TODO: [HIGH] Describe service and desktop file setup`, and only then the line that launches the program. So the documented path for a pip install stops short of describing how the tool registers itself with the desktop session. The same block also mixes comment styles: the Debian recipe is annotated with a single hash while the Arch, Fedora and openSUSE recipes use two, inside one continuous listing that reads as a single script.

Four distribution recipes and two ways of handling Tesseract headers

The four recipes are not equivalent. The Debian and Ubuntu line installs build-essential, tesseract-ocr, tesseract-ocr-eng, libtesseract-dev, libleptonica-dev and wl-clipboard, so it gets both development headers and the English language data. The Arch line installs tesseract, tesseract-data-eng and wl-clipboard, which is the engine and the language data but no headers at all. The Fedora line installs tesseract and wl-clipboard and nothing else, so neither headers nor language data. The openSUSE line installs python3-devel, tesseract-ocr, tesseract-ocr-devel and wl-clipboard, which is the one distribution that pairs headers with the engine without naming a language data package. The development prerequisites elsewhere in the file ask for Tesseract 5.0 or newer including language data, so the Fedora recipe does not meet the project's own stated bar.

The dependency list uses exact pins and leaves one package unexplained

All four runtime dependencies are pinned to a single version with no range at all: shiboken6 at 6.11.1, PySide6-Essentials at 6.11.1, jeepney at 0.9.0 and zxing-cpp at 3.1.0. That holds the Qt bindings and the QR and barcode reader steady, and it also means a patched release of either cannot be picked up without a metadata change. The Credits section accounts for pyside6, tesseract, zxing-cpp, wl-clipboard and xclip, and jeepney appears in neither that list nor anywhere in the prose, so one of the four installed packages has no stated role. Tesseract itself is not a Python dependency at all, which is why every platform recipe has to install the engine separately. Nothing else in the project file relaxes the habit: the optional build extra lists babel and toml with no versions, while the development group pins briefcase at 0.4.4. The root also carries uv.lock for a reproducible developer environment, .env.test, an adr/ directory for recorded decisions, mkdocs.yml with docs/ behind the published documentation, and bundle/ for the standalone app bundles.

The version has read 0.6.0 while a year of commits went past it

The package metadata pins version 0.6.0, and the three most recent releases are v0.6.0 dated 2025-08-31, v0.6.0-beta2 dated 2025-05-05 and v0.6.0-beta1 dated 2025-04-21. The last recorded push to the default branch is 2026-09-18, so the source has moved well past the newest tag while the version string and every installer link in the file still point at the 2025-08-31 assets. The classifier still reads Development Status 4 - Beta. Because the file tells you to choose one option for a prebuilt release, the Flathub, AUR and PyPI routes all serve that older build unless you build from source yourself.

The Flatpak route is two commands and the AppImage route is retired

Linux is directed to Flathub first, and the recipe is short enough to fit in two lines:

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak install flathub com.github.dynobo.normcap

Below it sit two alternatives. The AppImage is marked deprecated in the file and carries the note that AppImages require fuse to run, so the fallback path for a distribution without Flatpak now points at a retired artifact and an extra system requirement. The remaining option is the AUR package for Arch and Manjaro, which is the one channel that would track a rolling distribution rather than a pinned release.

Development runs a different entry point than the console script

Setting up a development environment takes uv and Tesseract 5.0 or newer with language data, then five commands:

git clone https://github.com/dynobo/normcap.git
cd normcap
uv sync
uv run prek install
uv run python -m normcap

That last line is the third spelling of the same entry point in one file. The package metadata declares a console script named normcap bound to normcap.app:run, the Windows instructions tell you to run normcap after installing, and the Linux and macOS instructions tell you to run ./normcap, which reads as a downloaded file rather than an installed script. The repository root holds the matching pieces: uv.lock for a reproducible environment, .pre-commit-config.yaml for the hook that prek install registers, and a CHANGELOG with no release newer than the tag. The build configuration explains the rest. Hatchling is the backend with a custom hatch_build.py beside it, and the wheel excludes assets and every .po file while shipping .mo files as artifacts, so translations are compiled during the build. Babel sits in the optional build extra and again in the development group at 2.12.1 or newer. Translation work runs through Weblate, with a manual route through normcap/resources/locales/README.md that the file describes as more cumbersome.

The credits name an X11 tool that no recipe installs

The alternatives list sets out eight projects with no stated order: TextSnatcher for Linux, GreenShot for Windows and macOS, TextShot for Windows, gImageReader for Linux and Windows, Capture2Text for Windows, Frog for Linux and Textinator for macOS, and then a Text-Grab entry whose link is cut off partway through, so the list ends inside its own last address. The Credits section credits xclip as a command line tool for the X11 clipboard, while the Linux recipe installs wl-clipboard for Wayland and never installs xclip anywhere. Packaging is credited to briefcase, which appears in the development dependency group pinned to 0.4.4 behind a comment that is itself cut short.

Editorial conclusion

NormCap suits someone who wants text off the screen into the clipboard on all three desktop platforms and is willing to grant a screen recording permission to get it. Install from Flathub or a prebuilt installer and you get a build from v0.6.0 dated 2025-08-31; install from PyPI and you inherit a dependency set with no version ranges and an install recipe that still has an open item marked HIGH in it. Check the macOS unsigned-app step and the Tesseract headers for your distribution before starting, and confirm the license terms yourself, since the repository metadata and the package metadata disagree.

Frequently asked questions

Official sources

1. dynobo/normcap on GitHub
2. Issues
3. Project website
4. README
5. Releases