Sherlock: a Wayland application launcher with plugins, widgets and usage tracking

A launcher built by someone who wanted a specific launcher

Sherlock is described as a lightweight and efficient application launcher built with Rust and GTK4. It is meant to let you launch applications quickly with a user-friendly interface, giving a fast and highly configurable way to search, launch and track application usage.

The tracking part is what separates it from a plain command palette. A launcher that knows which applications you actually open can rank them differently from one that sorts alphabetically, which is the whole point of a launcher you keep in a hotkey.

The project also states where it came from, and the caution notice is worth reading before installing anything. The app is or was developed on Arch Linux with the Hyprland tiling window manager in mind, and it may cause errors or will not function on your system. If that happens, the author asks for an issue to be opened and says they will try to resolve it. That is an unusually candid framing, and it tells you the test matrix is one person's setup rather than a distribution matrix.

The practical consequence is that Sherlock is a good fit for a Hyprland user and a gamble for everyone else. The dependency list bears that out, since gtk-4-layer-shell is a hard requirement, and layer shell is how a GTK4 window is anchored to a Wayland surface layer, which is a compositor protocol rather than a portable idea.

The documentation lives in the docs directory of the repository, and the contributing guide is at .github/CONTRIBUTING.md, with the project asking you to read it before submitting a pull request.

Fallbacks are the feature that makes a launcher survive a dead command

Two of the feature groups stand out because they address a real failure mode in launchers rather than adding more surface.

The first is fallbacks. You can configure fallback behaviours for various commands and operations, with the stated purpose of ensuring a smooth experience even when certain commands fail or are unavailable. In practice this is the difference between a launcher that shows a broken entry and one that substitutes something that works.

The second is custom commands. You define your own commands and extend the functionality of the launcher, adding new features or workflows tailored to your specific needs. Combined with fallbacks, this is the mechanism for handling the commands that only exist on your machine, which on a tiling desktop is a long list.

Application aliases sit alongside them. You can assign aliases to your applications for better looks and quicker access, assign custom icons to them, and hide apps that you do not use and do not want cluttering up the launcher. The hiding feature matters more than it sounds, because a launcher that lists every binary in your PATH becomes unusable, and a config that excludes the ones you never launch is the difference between a tool you keep and one you stop opening.

Style customization is the other half of the configuration surface. You can fully customize the look and feel of the launcher, modifying themes and visual elements to match your preferences, and the repository carries a themes directory for that purpose.

Categories, sub menus and number key shortcuts

Search scoping is the part of the interface that decides whether a launcher stays fast as your command set grows.

The mechanism is the category launcher. You type the launcher alias and a space bar to only search within a specific category of commands, and categories are fully configurable, so you can define your own search scopes. The category launcher can also show a group for additional subcommands, which is a way to expose a small command set without polluting the top level.

There is a dedicated command line flag for the same idea. Starting Sherlock with the --sub-menu flag restricts the search to within a category, so the launcher can be bound to a key that opens a narrow view rather than the full list.

Shortcuts handle the opposite problem, the commands you want in one keystroke. You can use modkey + number shortcuts to quickly launch a command or app without having to scroll, and you can configure custom key binds for navigation. On a tiling window manager this is the normal interaction model, where the launcher is a mode you enter and leave rather than a window you manage.

A context menu rounds out the interaction model. It is a customizable context menu for additional application and launcher actions, for example opening a private browser window, and you can extend or overwrite existing actions from your sherlock_alias.json file or create custom ones for your commands. That file name is worth remembering, since it is where the per-application behaviour lives.

Widgets for music, weather, live API responses and Teams meetings

Sherlock has grown a widget system, and this is where the plugin ecosystem comes from.

The async widget sends API requests and displays their responses directly in the launcher, which the documentation positions as useful for integrating live data or external tools into your workflow. The music widget shows your currently playing song or video, and the weather widget shows the weather in your specified location. A Teams Event Launcher is included for joining upcoming Microsoft Teams meetings.

The dependencies explain how the music widget works. dbus is used to get the currently playing song, and openssl, with libssl-dev, is used for retrieving Spotify album art. So the media integration talks to the desktop session over D-Bus and fetches artwork over the network, which is a real dependency and one you can check before installing.

The separate plugin repositories extend the same idea. sherlock-wiki searches Wikipedia from within Sherlock using the bulk_text launcher, sherlock-dict looks up word definitions, sherlock-clipboard displays cliphist history inside the launcher, and sherlock-confetti is a shader-based animation that covers the whole screen. The bulk_text launcher named in the wiki plugin is a clue about the extension point, since a plugin can contribute a launcher that fetches and renders its own content.

Taken together, the widgets and plugins make Sherlock less a launcher and more a small command shell with a graphical front end. That is the main risk of the project as well as its appeal, since every widget pulls in its own service.

Installing on Arch, or building the Rust binary yourself

On Arch Linux the pre-built binary package installs with:

yay -S sherlock-launcher-bin

There is also a community-maintained git build, which tracks the repository rather than a release:

yay -S sherlock-launcher-git

The difference between the two is the usual one. The bin package is a pre-built artefact, so you get whatever the packager compiled; the git build compiles from source and tracks the tip of main, which is where new features land first and where breakage lands first as well.

Building from source needs the runtime dependencies, which are gtk4, gtk-4-layer-shell, dbus, libsqlite3-dev, librsvg and gdk-pixbuf2, plus rust and git. The clone and build are:

git clone https://github.com/skxxtz/sherlock.git
cd sherlock

cargo build --release

After the build you install the binary to your system:

sudo cp target/release/sherlock /usr/local/bin/

and the build directory can then be removed, which the documentation lists as an optional step:

rm -rf /path/to/sherlock

The repository also ships a Debian package build path, and the tree carries a packager.sh, a flake.nix and flake.lock for Nix, so there is more than one packaging route beyond the Arch ones. The Nix and Debian instructions live further down the project documentation, which is truncated in the readme.

The dependency list reads like a GTK application, not a launcher

The Cargo manifest is where the real scope of the project shows, and it is worth reading before you install.

The interface layer is gtk4 with the v4_6 and v4_12 features, plus gtk4-layer-shell 0.4.0, which as noted is how the window is placed on a Wayland surface layer. gdk-pixbuf handles image loading and cli-clipboard handles the clipboard.

The data and search layer is more interesting. glob and regex do the matching, levenshtein handles fuzzy distance, meval evaluates expressions, and rayon provides parallelism, so searching is not a plain sequential scan. serde and serde_json handle configuration, toml reads the config files, and xdg resolves the standard directories. rusqlite is the SQLite binding, and procfs reads from procfs, which is how the launcher learns about running processes on Linux.

The async and integration layer is heavier still. tokio with the full feature set, async-std, async-channel, futures, zbus for D-Bus, reqwest with the blocking feature for HTTP, simd-json for fast JSON parsing, and bincode and bytes for serialisation. The bincode dependency carries a serde feature, and there is a criterion dev-dependency, so the project benchmarks something.

The release profile is set up for a small, fast binary: opt-level 3, thin link time optimisation, codegen-units 1, debug off. The package metadata also declares assets from resources, and the repository carries resources, assets and themes directories, with a build.rs that presumably wires them in.

For context on the cadence, the version in the manifest is 0.1.14 and the last push was on 2026-04-25. Recent releases include v0.1.14-1, v0.1.14-2 and v0.1.14-3, the last two described as a hotfix and bugfixes for 0.1.14, which suggests a release that needed patching after it shipped. The project is GPL-3.0.

When a launcher is the wrong tool

There are several situations where Sherlock is the wrong answer, and the project itself is the best source for the first one.

The Arch and Hyprland origin is a real constraint. A Wayland compositor that does not implement the layer shell protocol will not place the window correctly, and there is no fallback described for that. The project says it may cause errors or will not function on your system, and asks you to file an issue if so. On a GNOME or KDE session, or on a compositor you did not choose, expect friction rather than a smooth install.

The version numbering tells a second story. Every recent tag is a suffixed variant of 0.1.14, and two of the last three are explicitly a hotfix and bugfixes. Combined with a last push in April 2026 and no release since August 2025, this is a project whose release discipline is loose. If you are deploying Sherlock to other machines, you will be pinning something that has already needed patching, and the Cargo.toml version string of 0.1.14 does not distinguish the patched builds from the original.

Third, the widget system cuts both ways. A launcher that can make API requests, talk to D-Bus for media metadata, and pull album art over the network is a larger surface than a plain launcher. If you only want to type a command and press enter, the extra moving parts are not buying you anything.

And fourth, the category and alias configuration is only as good as the file you write. There is no indication in the documentation that Sherlock can discover and rank applications better than a static list, so the usage tracking has to be fed by the launcher seeing every launch, and the value depends on your own habits.

Editorial conclusion

Adopt Sherlock if you run Wayland with Hyprland and want a launcher that tracks usage, falls back gracefully when a command fails, and takes plugins and widgets, since those are the features the surrounding ecosystem is built around. Skip it if you need a launcher that is not tied to the author's own desktop, because the project states it was developed on Arch with Hyprland in mind and may not work elsewhere. Verify first that your distribution ships a package, that gtk4-layer-shell is available for your compositor, and that the wayland protocol support matches what the launcher needs.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. Skxxtz/sherlock on GitHub