Shutter: a screenshot tool for Linux, still built around a Perl script

What the repository is: a Perl script with a plugin directory

Shutter is a screenshot tool for Linux, and the repository layout is small enough to read in a minute. At the top level there is a bin/ directory holding the executable, a share/ directory holding the resources that get installed alongside it, a t/ directory for the tests, a cpanfile listing the Perl dependencies, a Makefile, a CHANGES file, a COPYING file, a README, a TODO-GTK3.md, and a po2mo.sh script. The primary language is Perl, and the copyright headers make the lineage visible, naming Mario Kemper for the 2008 to 2013 work and then Google LLC with Alexey Sokolov for the 2020 to 2021 contributions. That is a project that has changed hands and kept going, which is why the release numbers are still in the 0.99 range and the changelog rather than a version scheme is the place to look for what changed.

The Makefile is the installer, and it is a hand-written one

There is no configure script, no CMake and no build system beyond a short Makefile with a handful of targets. The prefix defaults to /usr/local, the all target runs the translation script, and the install target depends on it. The install target itself is a list of install and copy commands.

install: all
	install -Dm644 $(srcdir)COPYING $(prefix)/share/doc/shutter/COPYING
	install -Dm644 $(srcdir)README $(prefix)/share/doc/shutter/README
	install -Dm755 $(srcdir)bin/shutter $(prefix)/bin/shutter
	cp -r $(srcdir)share/ $(prefix)/

The uninstall target is longer, because it has to remove the compiled translation files, the desktop entry, the man page, the metainfo, the pixmap and the hicolor icon set at every size the install put them in. That asymmetry is normal for a hand-written installer and it is a fair proxy for how much of the distribution surface a screenshot tool accumulates. The practical implication for a packager is that the file list is not declared anywhere, so a distribution package has to reconstruct it, and the prefix is hard coded rather than being derived from a packaging system.

Translations are compiled at install time, not shipped

The po2mo.sh script and the clean target together explain the translation story. The clean target removes the share/locale directory if it exists, which is the directory the script generates, and the all target runs the script before anything is installed. So the repository carries translation sources and the build step compiles them into the gettext message files that the running program reads, with the clean target able to remove them again for a source tree that should stay pristine. The uninstall target repeats the pattern per locale, checking for shutter.mo, shutter-plugins.mo and shutter-upload-plugins.mo before removing each, which tells you the program itself and the two plugin sets are translated separately. The naming, plugins and upload plugins, suggests the feature set is split across modules, and the share/ directory that gets copied wholesale in the install target is where those modules and their translations live.

Three layers of licensing, and the icon story

The licence situation is layered and worth reading before you redistribute anything. The main licence is GPL 3 or, at your option, any later version, stated both in the README and in the licence text itself, with the standard notice that the software is distributed in the hope that it will be useful but without any warranty. The cursors are separately licensed under GPL2 or later, because some of the drawing tool cursors are based on or taken from the Inkscape project. The Gnome icons are also GPL2 or later. The Tango icons are a different story again: in the preparation of the 0.8.90 release Novell tracked down all the contributors in order to get them to relicense their artwork into the public domain, and the COPYING file in the tarball says the icons are released into the public domain, with the copyright status tracked in the CVS and the rdf properties of the SVGs adjusted to link to the Creative Commons public domain dedication. So a single install carries four different terms, and the icon situation is the kind of detail that only stays clean because somebody did the work.

Where to report a problem, and who is listening

The project publishes three contact routes and they are not interchangeable. For general contact there is an email address on the project site and an IRC channel at ircs://irc.libera.chat:6697/#shutter on Libera Chat. For bug reports there is a dedicated issue URL that pre-selects the bug label and the bug report template, and for questions there is a separate issue chooser. The distinction between the two GitHub links is a small thing that shows the project is run on GitHub properly, with a template for a structured report and a place for everything else that does not belong in a bug tracker. The project homepage is shutter-project.org, and the downloads are on the same site, which is where a user who is not building from source would go.

The GTK3 question, sitting in a TODO file

The most informative single file in the repository is TODO-GTK3.md, and the fact that it is a separate document at the top level tells you the move to GTK3 is unfinished rather than planned. The rest of the repository still looks like a Perl desktop application with a hand-written installer, and a toolkit port is exactly the kind of work that sits in a todo list for a long time because it touches every dialog. The CHANGES file is where you would look for what actually changed between versions, and the release history gives the shape: v0.99.7 on 2026-05-09, v0.99.6 on 2025-03-02 and v0.99.5 on 2024-03-31 with a release note of more bug fixes. The last push to the repository was on 2026-08-27, so the project is still being worked on, and it is not archived.

What this project is for, and where it is the wrong choice

Shutter is for people who take a lot of screenshots on a Linux desktop and want more than a keybinding that copies the screen to the clipboard. The plugin directory in the share/ tree, with its own translation catalogue separate from the main program's, is the structural hint that the tool is built around extendable pieces, and the upload plugins naming suggests at least one piece for sending an image somewhere rather than only saving it. The wrong choice for some people is straightforward. A user on a modern GNOME or KDE session usually has a built-in screenshot tool that handles the desktop portal, notifications and the modern screenshot UI contract, and a standalone window that predates that contract will not integrate as smoothly. A developer looking for a modern codebase to extend will find Perl and a half-finished GTK3 port, which is a heavier lift than starting from a current toolkit. And a distribution that wants a clean package will have to reconstruct the install manifest, because the Makefile is the only description of what gets installed.

Editorial conclusion

Shutter fits a Linux desktop user who wants a screenshot tool with annotation, delayed capture and upload support, since the project has been maintained across a long span of releases and the plugin directory is where those features live. It does not fit a developer who wants to extend the tool with a modern toolkit, because the primary language is Perl and there is a TODO file recording the unfinished move to GTK3, which tells you the current widget stack is the one being left behind. It also does not fit a distribution packager who wants a declarative build, because installation is a hand-written Makefile that assumes a prefix of /usr/local. Before you build from source, read the TODO-GTK3.md file to see what state the port is in, and check the CHANGES file for the behaviour of the version you plan to install, since the release numbers are still in the 0.99 range and the last one was v0.99.7 on 2026-05-09.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. shutter-project/shutter on GitHub