Clapper is a GTK4 media player built on GStreamer with a queue you can drag

A GNOME player for the everyday video, not a media library

Clapper is a video player written in C for the GNOME desktop. The README states the goal in plain terms: to offer all the essential features you would expect from a video player in a simple form. The stack is GStreamer for media handling and GTK4 for the interface, and the project carries the topic tags you would expect for a player of that kind, including flatpak, gnome, gstreamer, gtk4, hardware-acceleration and media-player.

That combination decides who the project is for. Anyone who has already accepted GStreamer as the multimedia stack on a Linux desktop will find the dependency model familiar. Anyone arriving from a platform with its own media framework will find the same, since the codec and container support is GStreamer's rather than Clapper's. The README makes the point explicitly for the Flatpak build: the package includes all required dependencies and codecs.

The deliberate simplicity is worth reading as a design choice rather than a missing feature list. The README describes one distinctive feature in detail, the playback queue, and does not enumerate things like subtitles, playlists of remote streams, or library management. What Clapper appears to be is a small, fast player that does the common job well, with the plugin surface left to GStreamer and to the separate libraries the project publishes.

The queue is the feature: multiple files, reordered by drag and drop

The one behaviour the README spends a paragraph describing is the playback queue. You can add several media files to it, and the text compares it to a playlist you build up over time. Items can be reordered or removed with a drag and drop operation, which is the part that separates it from a bare file open dialog.

The mechanism is straightforward enough that it needs little elaboration, but the design implication is real. Once a player has a queue, it is a session object rather than a viewer, which changes what the interface is for: the list itself becomes the primary surface, and controls act on the current position in it. That is a different shape from a player that just shows whatever file was last double-clicked.

It also changes what a user expects from the file manager. Dropping a file into the window is no longer a one-off act but an insertion into an ordered list, and the drag and drop gesture has to work in both directions: adding files in, and repositioning them within the queue. The README describes the reordering and removal as simple, and the project credits the maintainer of the package build files and two contributors who helped with testing the V4L2 and NVDEC hardware acceleration methods, which suggests those areas were worked on with outside input rather than guessed at.

Two libraries, one application, and an API that is not settled

The codebase splits into two libraries that the main application is built on. Clapper is the playback library, ClapperGtk is the GTK integration library, and both carry GObject Introspection bindings, which is what makes them usable from Python or any other introspection-aware language. The README points at the `examples` directory in the repository for usage, and the repository root does contain an `examples/` tree with a `clapper-gtk` example.

Bindings beyond the C API are part of the plan rather than an afterthought. Vala bindings live in this repository, and Rust bindings are maintained separately and published on crates.io as the `clapper-player` and `clapper-player-gtk` crates, with credit going to JanGernert for that work. GObject Introspection plus a maintained Rust crate is a fairly complete story for embedding the player in another application.

The caveat is stated just as clearly. The two libraries are licensed under `LGPL-2.1-or-later`, which the README says means you are free to use them in your own projects as long as you comply with the licence terms. It then adds the sentence that matters more in practice: until version 1.0 they should be considered an unstable API, and some things may change without prior notice. The current application release is 0.10.0, so that warning still applies. An embedder is signing up for a moving target.

Getting Clapper onto a machine: Flathub, distribution packages, or source

The README lays out three routes, and the first is the recommended one for most users. The Flatpak package on Flathub bundles every dependency and codec the player needs, so there is no multimedia stack to install first. It also carries a small set of patches that make some functionality work better than in the source build, because the README notes those changes have not been accepted upstream. The list of patches is tracked in issue 35, so the exact set can be checked rather than guessed.

For people on distributions that package Clapper, the README points at a Repology badge showing the packaging status across repositories. Two unofficial routes are named as well. An AppImage is maintained by the pkgforge-dev project, and pre-built RPM packages are published in the author's own openSUSE repository. The README is candid about those RPMs: they are built automatically on each git commit and are therefore considered unstable. That is a genuine distinction between a distribution's reviewed package and a rolling rebuild of the branch.

The source route is a standard Meson build:

meson setup builddir
cd builddir
meson compile
sudo meson install

One extra step appears if you want the Flatpak rather than a native build: clone the repository with the `--recurse-submodules` option, because the Flatpak build needs the submodules present. The repository root carries a `.gitmodules` file, and the packaging support lives under `pkgs/` with an `.obs/` directory for openSUSE build service configuration, which lines up with the RPM packages mentioned above.

Two licences in one repository, and what that means for reuse

The repository root holds two licence files, `COPYING-GPL` and `COPYING-LGPL`, and they cover different things. The application is released under GPL-3.0. The Clapper and ClapperGtk libraries are under `LGPL-2.1-or-later`, which is the permissive-in-practice option for a library: linking it from your own code is allowed provided you comply with the terms.

For a person who only installs the player, none of this matters. For someone planning to embed the playback library in their own application, the split is what makes the project usable at all, and it is the reason the libraries exist as separate artifacts with public documentation pages for each.

The documentation points to separate pages for the two libraries, a `Clapper` page and a `ClapperGtk` page, under the project site. The README does not walk through the compliance steps for the LGPL beyond that statement, and this is not legal advice, but the practical point stands: a consumer of the libraries has obligations that a consumer of the application does not, and the two should not be treated as one question. The licensing picture is unusually clear for a project of this size, and the README states the arrangement without hedging.

Release cadence: 0.10.0 shipped in December 2025, the branch moved in September

The maintenance picture is worth reading carefully rather than summarising as active. The repository is not archived, and the last push was on 2026-09-30. The tagged releases are more spread out: 0.10.0 on 2025-12-22, 0.8.0 on 2025-01-20, and 0.6.1 on 2024-07-01. So the most recent tag is close to ten months old, while the branch itself has seen commits more recently than that.

That gap between tag and branch is normal for a project that tags releases when it chooses to, but it has a consequence for anyone tracking releases rather than the branch. A feature merged after December 2025 may not exist in any published binary yet, and the automatically built RPM packages, which the README already labels unstable, are the closest thing to a continuously updated build.

The CI setup supports both models. The repository has workflows for the Flatpak build on push and for a Flatpak nightly on a schedule, and the project is translated through Crowdin, where the README notes that only the maintainer can add new languages. Localisation through a web browser with no extra tooling lowers the barrier for contributors, and it also means the translation pipeline depends on one account holder.

Project direction is discussed on Matrix, in the #clapper-player room, and funding runs through Liberapay. A single maintainer coordinating release tags, Crowdin access, distribution repositories and the Flatpak patches is the structural fact that most affects how quickly anything else changes.

Where Clapper is the wrong choice

There are clear boundaries. The first is platform. Every documented install route is Linux: Flathub, distribution packages, an unofficial AppImage, and a Meson build that assumes a GStreamer and GTK4 system. There is no Windows or macOS build described, and the README does not mention one.

The second is that Clapper is a local player. Nothing in the documentation describes streaming from a network location, casting to a television, or syncing playback state between devices. If your media lives on a remote server and you expect the player to pull it over a network share, that capability is not documented and you would need to confirm it in the source before assuming it.

The third is the unstable API warning, which applies to anyone building on the libraries rather than installing the application. Code written against Clapper 0.x may need revisiting when the author declares 1.0, and the README gives no deprecation policy or migration guide for that transition.

Against browser-based playback, the difference in approach is straightforward. A browser tab plays whatever the codec stack of the browser supports, with no installation and no queue beyond the tab's own media session. Clapper is a native application that relies on GStreamer for decoding, which means broader codec coverage on a Linux desktop and a persistent queue, at the cost of installing software and keeping it current.

Editorial conclusion

Clapper fits a Linux desktop user who wants a native GNOME player with a reorderable queue and would rather install a Flatpak than assemble GStreamer dependencies, and it fits a developer who wants a C playback library with GObject Introspection bindings rather than a JavaScript wrapper. It does not fit a user who needs a stable library API, since the README asks you to treat both libraries as unstable until version 1.0, and it does not fit a Windows or macOS user, since every documented install route is a Linux one. Verify three things before depending on it: check that the Flatpak build carries the patch set listed in issue 35 if you need the features that depend on them, confirm the distribution package you pick is not one of the automatically built RPMs that the README calls unstable, and read the `LGPL-2.1-or-later` terms of the two libraries separately from the `GPL-3.0` terms of the application itself.

Frequently asked questions

Official sources

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