Walker: a GTK4 application launcher for Wayland that puts providers behind Elephant
Multi-Purpose Launcher with a lot of features. Highly Customizable and fast.
At a glance
- What is it?
- Walker is a Rust and GTK4 launcher for Linux desktops. It splits the UI from the data sources: Elephant runs the providers, Walker draws the results, and every list layout is editable XML.
- Who is it for?
- Adopt Walker if you run a Wayland desktop, are comfortable with GTK4 and CSS, and want each provider's list rows designed in XML rather than a fixed theme. Do not adopt it if you want a launcher that starts on its own or works on X11, since the crate list includes gdk4-wayland and gtk4-layer-shell and the README says Elephant must be running before Walker starts.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What Walker solves, and who ends up using it
A launcher looks like a solved problem until you want one list to show installed applications, another to show files, and a third to show Arch packages with an install action. Most launchers hard-code those lists and the row template that draws them. Walker separates the two halves. The README describes Walker as a fast, customizable application launcher built with GTK4 and Rust for Linux desktop environments, and lists the providers it implements by default: desktop applications, calculator, file browser, command runner, websearch, clipboard history, symbol picker, provider list, menu integration, dmenu, Arch Linux packages, todo list, bookmarks, Bluetooth, Niri actions, Niri sessions, Bitwarden and 1Password, Wireplumber, snippets, and windows.
That list is the actual pitch. The audience is people who already live in a keyboard-driven Wayland session and want the launcher to reach into package management, passwords, sound, and window focus from the same input box. If you only want to type an app name and press Enter, the provider list is more surface area than you need. The README is also explicit that the providers are Elephant providers, which matters for how the project is installed and run.
Elephant runs the providers, Walker draws the results
The architecture is a split process model, and the README states it plainly: make sure elephant is running before starting Walker, and you need providers installed, naming elephant-providerlist and elephant-desktopapplications as examples. So Walker itself is the GTK4 front end. It owns the window, the search field, the list rendering, the theme, and the keybinds. The data comes over from Elephant, which hosts the providers.
The dependency list in Cargo.toml backs that reading. The crate pulls gtk4 with the v4_6 and v4_12 features, gtk4-layer-shell, gdk4-wayland with the wayland_crate feature, wayland-client, wayland-backend, and wayland-scanner. There is no X11 backend in that list. The presence of gtk4-layer-shell is what lets the window sit on a layer surface rather than as an ordinary toplevel, which is how launchers usually get placed on Wayland compositors.
The other half of the mechanism is rendering. The README says each provider's list items can be rendered individually, and gives the example that item_files.xml defines the layout for items sourced from the files provider. Themes inherit the default theme by default, so a theme that only changes colors can be a single style.css. That is a real design decision: the layout language is XML per provider, the styling language is CSS per theme, and you can change one without rewriting the other.
Building Walker from source and running it once
The README gives a from-source path. It clones the repository, builds with Cargo in release mode, and runs the binary out of target/release. Before any of that works, the dependencies section lists GTK4 version 4.6 or newer, gtk4-layer-shell, the Protocol Buffers compiler, cairo, and poppler-glib. It also repeats the runtime requirement: make sure elephant is running before starting Walker.
git clone https://github.com/abenz1267/walker.git
cd walker
cargo build --release
./target/release/walkerIf the build fails, check the dependency list first rather than the Rust code. protobuf and poppler-glib are the two that are easy to miss on a minimal system, and the build script uses protoc-bin-vendored, which suggests the Protocol Buffers compiler is needed at build time as well as at runtime.
For a first real use, the README describes a service mode. Running walker --gapplication-service starts a background service so that later launches are faster. Once that service is up, a plain walker call opens the window, or you can make a socket call for an even faster launch.
walker --gapplication-service
walker
nc -U /run/user/1000/walker/walker.sockThe README notes the downside of the socket path directly: it does not handle any commandline options, so it is just a faster alternative to a simple walker call. If you rely on flags, use walker and not the socket.
Configuration lives in ~/.config/walker, and the README points at a default config.toml in resources/config.toml as the reference. The Nix path is documented separately, with flake inputs for both walker and elephant, where walker is set to follow the elephant input, and three install options: a home-manager module, a NixOS module, or the package itself. The README warns that the NixOS module does not support the runAsService option and recommends launching the elephant and walker services from your desktop instead, and that the package option does not support configuration through Nix.
Prefixes, keybinds, and the parts that surprise people
Walker's input box is prefix-driven. The README lists the default prefixes: = for the calculator, / for the file browser, : for clipboard history, . for the symbol picker, and ; for the provider list. If you have used a launcher before, this is the part that changes muscle memory, because the prefix decides which provider answers your query and therefore what the list shows.
Keybinds use GDK key values. The README says the valid modifiers are ctrl, alt, shift, and super, and points at the GDK key-value list for everything else. It gives a worked example: the constant GDK_KEY_semicolon means ctrl semicolon is a valid keybind. That is a concrete instruction rather than a vague pointer, and it is the kind of documentation that saves an afternoon.
The Nix configuration example in the README shows how the pieces fit together. It sets a theme name, defines placeholders for the default input and list, reassigns prefixes so that websearch uses + and providerlist uses _, and binds quick_activate to F1, F2, and F3. Themes are declared as a set, each with a style string and a map of layouts, and the README points at resources/themes/default/style.css and the default layouts directory as the examples to copy. The comment in the example is direct about the theme field: set programs.walker.config.theme to your theme name to choose the default theme.
Where Walker is the wrong choice
The first limitation is not a bug, it is the architecture. Walker does not work without Elephant. The README says to make sure elephant is running before starting Walker and to have providers installed. A user who wants a single self-contained binary that starts, shows apps, and exits will find the two-process setup heavier than expected, and a broken or missing Elephant turns the launcher into an empty window.
The second is platform. The dependency list includes gdk4-wayland, wayland-client, wayland-backend, and gtk4-layer-shell, and no X11 backend appears. The repository topics are runner, rust, and wayland. If your session is X11, this is not the launcher for you, and the README does not offer an X11 path.
The third is the Nix surface. The README is specific that the NixOS module does not support runAsService and that the package option does not support configuration through Nix. So the most convenient install route and the most configurable one are not the same route, and picking the package form means editing config.toml by hand.
The fourth is documentation depth. The README is a good map but not a manual. It links a GitBook wiki for the details and refers to the GTK4 docs for theming, which means the layout XML format is learned by reading the default theme files rather than from a written specification. That is workable for someone comfortable with GTK4, and a real cost for someone who is not.
How Walker differs from rofi and wofi
The obvious comparison is rofi, and the difference is the provider model rather than the widget. Rofi is a single process that reads a list from stdin or from its own modes, and its theming is a rasi stylesheet. Walker pushes the data sources out to Elephant, so a new capability is a new provider process rather than a new mode compiled into the launcher, and it draws each provider's rows from its own XML layout file, with item_files.xml as the README's example.
Wofi is closer in spirit, a GTK-based launcher for Wayland, but it is a menu front end. It does not ship Arch package search with install and delete actions, a todo list with scheduling and notifications, Bitwarden and 1Password access, Wireplumber control, or Niri session sets. Those are all in Walker's default provider list. Whether that breadth is a benefit depends on whether you want your launcher to be the entry point for package management and password access, or only for starting programs.
The trade is startup complexity. Rofi and wofi are one binary. Walker is a front end plus Elephant plus whichever provider packages you install, and the README's service mode and socket call exist precisely because that model has more to warm up.
Licence, maintenance, and what an upgrade costs
Walker is GPL-3.0, per the repository licence and the badge in the README. If you fork it, ship a modified binary, or embed it in a distribution, the GPL obligations attach to the whole work in the usual way. That is a statement about the licence text, not legal advice, and anyone distributing a modified Walker should read the licence itself rather than this paragraph.
Maintenance looks current. The last push to the default branch was on 2026-09-15, and the most recent release listed is v2.17.0 from 2026-07-16, preceded by v2.16.2 and v2.16.1 in April and May. The Cargo.toml package version is 2.17.0, matching the latest release tag.
The upgrade cost is concentrated in two places. Themes inherit the default theme, so a theme that only overrides CSS survives most changes, but a theme that ships its own layouts is tied to the XML structure of the default layouts it was copied from. The provider list is the other moving part: because providers come from Elephant, a Walker upgrade and an Elephant upgrade are separate events, and the README's requirement that providers be installed means a new provider in a release is not automatically available to you. The Nix path adds a third: the flake pins walker to follow elephant, so bumping one input without the other is the failure mode to watch.
Editorial conclusion
Adopt Walker if you run a Wayland desktop, are comfortable with GTK4 and CSS, and want each provider's list rows designed in XML rather than a fixed theme. Do not adopt it if you want a launcher that starts on its own or works on X11, since the crate list includes gdk4-wayland and gtk4-layer-shell and the README says Elephant must be running before Walker starts. Verify first that GTK4 4.6 or newer, gtk4-layer-shell and the Protocol Buffers compiler are present, and that your desktop session actually starts Elephant. The README links a GitBook wiki for deeper configuration, and that wiki is where the layout and theme details live, not the README.
Frequently asked questions
How do I install Walker on Linux?
The README documents building from source with git clone, cargo build --release, and running ./target/release/walker, plus Nix flake inputs for walker and elephant with home-manager, NixOS module, or package options. Either way, Elephant has to be running before Walker starts.
How do I use Walker once it is installed?
Launch it with walker, or start walker --gapplication-service first so later launches are faster. Providers are reached through prefixes, including = for the calculator, / for the file browser, : for clipboard history, . for the symbol picker, and ; for the provider list.
Does Walker work without Elephant?
No. The README says to make sure elephant is running before starting Walker and that you need providers installed, naming elephant-providerlist and elephant-desktopapplications as examples.
What is the fastest way to open Walker?
The README describes a socket call as an even faster alternative to a plain walker call, using nc -U /run/user/1000/walker/walker.sock. The caveat it gives is that the socket call does not handle any commandline options.
Where does Walker keep its configuration and themes?
Configuration goes in ~/.config/walker, and the README points at resources/config.toml as the default config. Themes live under resources/themes/default, and a custom theme inherits the default theme, so changing only the CSS can be a single style.css.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/abenz1267-walker)