How does Albert's plugin system work?

Updated

Albert's plugin system is the mechanism that turns a keyboard launcher into a customizable command palette. The core application is written in C++/Qt and handles the launcher shell — hotkey, query input, result list, and action execution. Everything beyond that shell is a plugin. Plugins can either create frontends (the interface you interact with) or add functional extensions (the things Albert can find and do). Extensions can be written as embedded Python modules or exposed through a CGI-style approach in any language you choose.

The two roles a plugin can play

The site describes the architecture as "plugin based" and says plugins "can be used to create frontends or functional extensions." That distinction matters when you plan your own integration:

Plugin role What it provides When to choose it
Frontend The user-facing surface — how queries are entered and results are shown You want a different interaction model, not just new searchable items
Functional extension New items, actions, or commands that appear in results You want Albert to find or do something new while keeping the standard interface

For most users, the practical question is the second row: how do I make Albert search my own data or trigger my own actions? That is an extension, and the architecture gives you two implementation routes.

Route 1: embedded Python modules

The site states that extensions "can also be implemented using embedded Python modules." The word embedded is the key detail: Python runs inside Albert's process rather than as a separate program. In practice this means your extension is a module Albert loads, and the launcher calls into it when a query arrives.

This route suits you if:

  • You want the shortest path from idea to working extension.
  • Your logic is self-contained — querying a local file, calling a small API, computing a result.
  • You are comfortable with Python and prefer not to manage a separate process.

The site also says Albert "offers APIs designed to be simple and easy to learn" and "provides a set of powerful utilities" so common tasks need minimal code. Those utilities are what you should look for first before writing plumbing yourself.

Route 2: CGI approach in any language

The second route is a "CGI approach in any language you want." Here the extension is not loaded into Albert's process; instead Albert invokes it in the CGI style — the launcher passes the query in, your program writes a response out, and Albert renders the results. The language is your choice because the contract is the CGI interface, not a language binding.

Choose this route when:

  • Your extension is already a script or binary in another language (Go, Rust, a shell script, Node).
  • You want process isolation — a crash or hang in your extension should not take the launcher down with it.
  • You are wrapping an existing command-line tool and want its output to appear as Albert results.

The trade-off is the interface boundary: you are responsible for formatting output correctly, and you give up direct access to in-process APIs. The Python route is more tightly integrated; the CGI route is more portable.

What "flexibility" actually buys you

The site frames the plugin system as the reason Albert "could be your go-to app launcher or a full-blown system command palette." That is the concrete payoff of the frontend/extension split: the same core can present very different products depending on which plugins are loaded. A minimal setup behaves like a fast app launcher; adding extensions turns it into a place where you run system commands, query services, and trigger workflows from one input field.

Two supporting claims from the site are worth noting because they affect day-to-day use rather than architecture:

  • Performance is a primary design goal. The site says Albert is "designed to be fast" and can keep up with users who type at 200+ KPM. A plugin architecture can undermine speed if extensions are slow, so treat extension latency as part of your design.
  • A curated plugin collection ships with it. The site describes "a curated collection of peer-reviewed, actively maintained plugins" with "no searching, no duplicates, no broken code." For most users, the first step is not writing an extension but checking whether a maintained plugin already covers the task.

A practical way to decide

  1. Check the bundled collection first. If a maintained plugin does the job, use it — the site explicitly positions the included set as working out of the box.
  2. If you need custom behavior, start with Python. It is the lower-friction route and gives you Albert's APIs and utilities directly.
  3. Move to CGI only when you have a reason. An existing tool in another language, or a need for process isolation, are good reasons; novelty is not.
  4. Test with realistic query volume. Because speed is a stated design goal, measure how your extension behaves under fast, repeated typing rather than a single slow query.

The one thing the site does not specify is the exact plugin API surface or the precise CGI request/response format. Those details belong in the project's developer documentation, and you should confirm them there before writing code rather than assuming a shape from the architecture description alone.