kew: the README points at a website and leaves the install to it

The front page is a pointer rather than a manual

The repository description says Music for the Shell, and then the install, usage and contribution instructions are handed to an external site in a single sentence. There is no build command, no dependency list and no key binding table anywhere in the front page. Eighteen features are listed instead, from auto-generated playlists keyed on words in an artist, album or song name, through gapless playback, sixel cover art, a spectrum visualizer, a music library explorer, playlist editing, search, lyrics, replay gain, custom layouts and auto-resume. Only one of the eighteen is marked experimental, and that is crossfade, in both its automatic and its on-demand form. So what you get from the repository is a capability list and a URL, and the documentation itself lives somewhere the repository does not contain.

Private and offline, with one exception the project added on request

One feature bullet reads private and offline, and it carries an asterisk rather than standing alone. The footnote is the interesting part: kew can display a listening status in Discord, but the text records that this is now opt-in by popular demand. The phrasing matters twice over. The capability existed before the opt-in did, so the network path was added first and the default was tightened after people objected. And the reason given is demand, which is a description of how a decision was reached rather than a technical constraint. Two documents sit at the repository root that match the claim and are worth reading: a PRIVACY_POLICY.md and a TERMS.md. Between them, the offline claim has an escape hatch, a default that no longer uses it, and a written policy, which is more than most projects of this size bother to publish.

Three platforms get three different desktop integration paths

The build file picks its notification mechanism by platform, using three separate auto-detection blocks. DBus is enabled only when nothing else matches: it is forced off on Darwin, on Android and on the MinGW and MSYS environments, and left on everywhere else. A second block turns a macOS media path on for Darwin and off elsewhere. A third turns Windows SMTC on for MinGW and MSYS and off elsewhere. Each block is guarded by a check that the variable has not been set from outside, so an explicit value on the command line beats the platform logic. That override is the interesting part, because it lets a combination the platform rules would not choose be built deliberately, on a Mac with DBus or on Windows with DBus. The net effect is that Linux desktops, Macs and Windows each get a different route to the same player controls.

CAP_SYS_NICE is offered at install time and it breaks MPRIS

Five build switches are documented in comments at the top of the Makefile: DEBUG, USE_DBUS, USE_FAAD, ENABLE_CAP_SYS_NICE and PREFIX, alongside SYMBOLS and STRIP which default to zero. Four of them turn something off. The fifth is the one to read carefully. Running the install target with ENABLE_CAP_SYS_NICE set to 1 asks the installation to grant the capability that permits real-time scheduling, and the comment attached to it warns in plain words that this breaks MPRIS on some systems, pointing at the section on real-time scheduling in the manual install instructions. That is a genuine tradeoff stated by the project rather than discovered by a user: better scheduling priority in exchange for a desktop media integration that may stop responding. Nothing in the feature list mentions it, and it is the only place in the file where a documented setting is admitted to degrade another advertised feature.

m4a is supported and fragmented mp4 inside it is not

The format list divides into two tiers and the boundary runs through a single container. Supported: mp3, flac, opus, ogg, m4a including alac, raw aac, wav and webm. Then a second heading reads with caveats, not supported, and names three things: HE-AAC, E-AC-3, and m4a with fragmented mp4s. That third entry is the awkward one, because m4a appears in the supported list and m4a with fragmented mp4s appears in the unsupported one. The extension alone therefore does not tell you whether a file will play. The other two exclusions matter for anything sourced from streaming services rather than from a local rip. Nothing in the front page states how the player reports a rejected file, so whether you get a silent skip or an error is not something the repository answers.

Two tags eleven minutes apart, and a version read out of git

The release list shows v4.3.6 dated 2026-09-22, then v4.3.7 at 16:10 on 2026-09-26, then v4.3.8 at 16:21 the same day. The last two are eleven minutes apart, and the repository was pushed to on 2026-10-03, so the working tree is ahead of every tag. The version the binary reports is not read from a file at all. The Makefile sets it from a call to git describe with tags, dirty and always, which means the number follows whatever the checkout happens to be, and a tree with local modifications gets a marked version rather than the clean tag. That is convenient for a developer building from source and unhelpful for anyone trying to tell two local builds apart from two released ones.

A GPLv2+ README against a GPL-2.0 license field

The license section states GPLv2+, while the license recorded for the repository is GPL-2.0. Those are not the same grant. GPL-2.0 on its own means version 2 only; the plus means any later version is also permitted, which is a materially different set of obligations for whoever links against it. Nothing in the repository resolves the discrepancy, and the LICENSE file at the root is the place to settle it. Two smaller inconsistencies sit alongside. The star lines at the bottom of the page read Github Stars and Codeberg Stars, and both are empty links, so neither count is visible and the Codeberg mirror is announced only by the label. The header is built the same way, with two band links wrapped in anchors that have no text, and a version badge for the Repology package index in the same empty form.

Localization runs through gettext, a Chinese README and a second makefile

Translation is wired at four levels rather than one. A `locale/` directory and a `po/` directory hold the message catalogues, a `kew.pot` file at the root is the template they are generated from, and a separate `Makefile.i18n` exists so that translation work does not have to run through the main build. Alongside that sits `README_zh_CN.md`, a Chinese front page as a first-class document rather than a wiki page. Packaging is just as spread out: a `flake.nix` for Nix, a `com.kewplayer.kew.yml` manifest that reads as a Flatpak definition, and an `installer.iss` for a Windows installer, next to a `kew.ico` icon and a `manifest.res` resource file. Android is detected by probing for a Termux directory rather than by a build flag, and three editor configuration files, `.clang-format`, `.clangd` and `.editorconfig`, sit at the root.

Editorial conclusion

kew fits someone who wants gapless playback, replay gain, cover art and a library browser inside a terminal, and it does not fit someone who needs HE-AAC, Dolby Digital Plus or fragmented mp4 files to play. Verify three things first. Read the install material on the project website, because the front page carries none. Decide which of the three desktop integration routes you want, since DBus, the macOS media path and the Windows SMTC path are selected by platform and can each be overridden from the command line. And settle the license question yourself, because the README says GPLv2+ while the recorded license field says GPL-2.0, and the two differ on whether a later version is allowed. The optional Discord status is genuinely opt-in, which is the one privacy claim worth checking.

Frequently asked questions

Official sources

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