Vicinae: a native C++ command palette that runs Raycast extensions on Linux

What Vicinae actually replaces on a Linux desktop

Most Linux launchers start as an application menu and grow features sideways. Vicinae starts from the opposite direction: the README describes it as a "high-performance, native command palette for your desktop" and then lists what it can be out of the box. That list is the real scope statement. App search, clipboard history, snippet expansion, file search, a browser tab switcher, an emoji picker, a calculator, a window and workspace switcher, a font browser, and a volume controller are all first-party features rather than plugins you install separately.

The target user is someone who already lives on the keyboard and has been assembling that same set of tools from four or five unrelated programs. If you currently run one binary for clipboard history, another for emoji, and a shell script for snippets, Vicinae is arguing that these belong in one process with one keybinding. The second audience is Raycast users who moved to Linux or who split time between macOS and Linux, because the extension story is explicitly built around Raycast compatibility rather than a Vicinae-only API.

It is not a general-purpose application framework, and it is not trying to be a tiling window manager or a status bar. The window and workspace switcher is a view onto what your compositor already does.

Native C++ with QML on top, and where the extension code runs

The repository layout tells you the architecture before you read a line of it. src/ holds the C++ and QML sources, vendor/ holds third-party code, and figura/ plus the FIGURA_CC variable in the Makefile point at an in-tree tool built to build/bin/figura. The language mix is C++ with QML for the interface, which is why the Makefile carries a qmllint target and why .qmlformat.ini sits at the top level. This is a compiled native application, not a web view with a native shell around it.

Extension code follows a different path. The README states that Vicinae supports "React/Typescript extensions" that are "compatible with the Raycast ecosystem", and that the application has in-app integration with both the Vicinae store and the Raycast store. Script commands are also described as compatible with the Raycast feature of the same name, "with special Vicinae additions". So the data flow is split: the launcher core is native and stays resident, while extensions are authored in TypeScript and loaded by that core. The third extension route is dmenu-style menu creation, which the README calls "the linux minimalist way" and which needs no JavaScript at all.

That split is the interesting design decision. Keeping the hot path native is what makes a launcher feel instant, and reusing Raycast's extension contract is what makes the ecosystem non-empty on day one. The cost is that Vicinae inherits whatever Raycast's API surface happens to be, including the parts that make sense only on macOS.

Installing Vicinae and running your first command

The README points to vicinae.com for getting started and does not spell out per-distro install commands, so treat the homepage as the entry point. What the repository does show is the build system, and it is unusually broad: flake.nix and flake.lock mean a Nix flake, default.nix and the nix/ directory mean a plain Nix expression, and the Makefile defines an AppImage build environment under scripts/runners/appimage/ with the image tag vicinae/appimage-build-env. The related searches around AUR and Fedora suggest packaged builds exist for those, but the README itself does not document them, so verify on vicinae.com before you assume a package name.

If you are building from source, the Makefile is the shortest path. The release target configures and builds through CMake presets:

make release

The Makefile sets PRESET_OS to macos on Darwin and linux everywhere else, so the same command picks the right preset for your platform. The preset names themselves live in CMakePresets.json, which is where you should look if you want to know what a release build actually enables.

For day-to-day work the Makefile offers a development loop that builds and then starts the server, replacing any running instance and opening the palette:

make dev

That expands to dev-run, which runs build/bin/vicinae server --replace --open after a dev-build. The --replace flag is the one to remember: without it you are fighting an already-running launcher for the same keybinding.

Once it is running, the README's own framing is the fastest way to a first real use. Open the palette, type an application name, and you have replaced your app menu. Then work through the built-in list one item at a time: copy something and open clipboard history, define a snippet and watch it expand, search for a file. Each of those is a first-party feature, so there is no extension to install before it works.

The extension compatibility promise has no published boundary

Raycast compatibility is the headline feature and also the least specified part of the repository. The README says extensions are compatible with the Raycast ecosystem, and that the app integrates with both stores in-app. It does not say which Raycast APIs are implemented, which are stubbed, or what happens when an extension calls something Vicinae has not built. There is no compatibility matrix in the README, and no version of the Raycast API is named.

That matters because Raycast extensions are not a frozen specification. They are written against a moving API, and a launcher that reimplements it has to track those changes or pin to a version and drift. Nothing in the README commits to either strategy. The practical consequence for a user is that "compatible with the Raycast ecosystem" is a direction, not a guarantee, and the honest way to evaluate it is to install the specific extension you care about and try it.

The second limitation is platform. The Makefile opens with the line that it is "only for use on UNIX systems" and that on Windows "you are expected to use cmake directly and utility scripts in ./scripts". That is a build instruction, not a supported Windows release. The macOS bundle identifier com.vicinaehq.Vicinae and the SoulverCore acknowledgment in the README show macOS is a real target, but the README's own feature list, with its window switcher and dmenu integration, reads as Linux-first.

A third boundary is the launcher model itself. If you want a system that indexes your entire home directory in the background and answers natural-language queries, this is the wrong tool. Vicinae is a palette: you invoke it, you type, you get a list, you pick.

Vicinae vs Walker, and what the difference in approach means

Walker is the comparison people search for, and the difference is not cosmetic. Walker is a GTK application built around a modular provider system where you configure which providers feed the launcher and how they are rendered. Its extension surface is configuration and external programs, and its visual layer is themeable through GTK styling.

Vicinae takes the opposite route on both counts. The core is C++ with QML rather than GTK, and extensibility is code-first: React/TypeScript extensions following the Raycast contract, script commands, or dmenu-style output. Where Walker asks you to wire providers together, Vicinae asks you to write or install an extension against an API that already exists elsewhere. The payoff is that a Raycast extension author's work is potentially reusable; the cost is that you are depending on a compatibility layer rather than a native plugin API designed for this launcher alone.

There is a second, quieter difference. Walker's provider model means the set of things it can do is visible in your configuration. Vicinae's built-in feature list is fixed by the application, and the extension store is where growth happens. If you prefer to audit exactly what your launcher can reach, the Walker model is easier to reason about. If you prefer a curated store and a TypeScript API, Vicinae's model is easier to extend.

Build cost, release cadence and the GPL-3.0 obligation

Vicinae ships releases quickly. The repository lists v0.27.4 on 2026-08-28, v0.27.3 on 2026-08-27, and v0.27.1 on 2026-08-26: three releases inside three days, and the last push to main was on 2026-08-28. A cadence like that is good news for bug fixes and bad news for anyone pinning a version and expecting it to stay put. If you package Vicinae for a distribution, budget for frequent rebases.

The build itself is not trivial. It is a C++ project with CMake presets, LTO available through the host-optimized target, a separate figura tool compiled into build/bin, QML linting, and a translation pipeline with update-translations and check-translations targets that diff src/server/translations. There is also a clang toolchain configuration at the top level (.clang-format, .clang-tidy, .clangd), which tells you the project expects contributors to run those tools. Building from source is a reasonable path for a Nix or Arch user and a poor first project for someone who has never touched CMake.

The licence is GPL-3.0. For a desktop launcher that most people install and run, that is unremarkable. It becomes relevant the moment you redistribute a modified build or bundle Vicinae into a larger product, because the copyleft terms attach to the distributed work. This is a description of what the licence is, not legal advice; if you are shipping Vicinae inside something commercial, read the LICENSE file and talk to someone qualified.

Editorial conclusion

Adopt Vicinae if you run a Linux desktop, already have a Nix or AUR workflow, and want Raycast-compatible extensions without a browser or Electron runtime. Skip it if you need a documented Windows build path or a stable extension API with a published compatibility contract. Before committing, check the CMakePresets.json presets your platform needs, confirm which of the two stores the extension you want actually lives in, and read the GPL-3.0 obligations if you plan to redistribute a build.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes