search-light: pulling the GNOME app search out of the Overview

The widget leaves the Overview and becomes a launcher

The extension's own description is the clearest statement of what it does: it is a GNOME Shell extension that takes the apps search widget out of Overview, like the macOS Spotlight or Alfred.

That is a small change with a large effect on daily use, because the GNOME Overview is a heavyweight mode. It is a modal overlay that shows the workspace switcher, the application grid and the search entry in one place, and entering it means the shell rebuilds a large amount of content and the search field receives focus. If the thing you do forty times a day is type an application name, paying that cost every time is the friction this extension removes.

The result is described as a popup search box, and the keybinding that opens it is Ctrl+Cmd+Space, changeable from the preferences page. The alternative key is the Windows logo key, called Super on Linux, or the command logo on a Mac keyboard. The README mentions the keybinding in a slightly garbled way, listing both the shortcut and the alternative Super key, but the intent is clear enough: the default is a three-finger combination that is chosen to avoid colliding with anything a desktop uses by default.

The feature list is short and specific: the popup search box, colours and background and border customisation, a blurred background, and multi-monitor support. There is no mention of a calculator, a clipboard history, a file finder with fuzzy matching or a launcher for shell commands, so the scope is the application search that GNOME already had, relocated.

That narrowness is worth stating up front, because Alfred and Spotlight are extensible and this is not. If what you want is a general launcher you can extend with your own actions, this is the wrong tool. If what you want is GNOME's own search without the Overview, it is exactly the right tool.

Branch per GNOME generation, and a Notice you should read first

The most operationally important part of the README is the Notice section, because it explains how version support is organised and it is unusual.

Gnome 48 is ready for testing. Gnome 47 and prior will now be in the gnome-47 branch. The Gnome 46 port is ready for testing, as is the Gnome 45 port, and Gnome 44 and prior live under the g44 branch. The README also describes the extension as a GNOME Shell 42 or newer extension, which is the baseline the metadata is written against.

So the model is a set of parallel branches rather than one branch that supports everything. That is what a GNOME Shell extension has to do, because the shell's internal JavaScript API changes between releases and an extension written against one version often simply fails to load on another. A project that keeps separate branches per generation is doing the honest thing, and the cost is that you have to pick the right one.

The word testing in the notice is also worth noticing. Two of the entries say ready for testing rather than ready, which tells you that the 45 and 46 ports are newer work and less settled than the 47 and 48 lines. If you are on a version whose port is still in testing, expect rough edges.

The repository carries a CHANGELOG.md, a HACKING.md and a NOTES.md, and a per-generation Makefile target, g44, which builds and installs the older branch. The presence of HACKING.md and NOTES.md suggests the porting work is documented somewhere beyond the README, which is where you would look if you are considering maintaining your own branch.

The blur needs ImageMagick, and that is a system dependency

One feature has a non-obvious dependency. The blurred background requires ImageMagick to be installed on the system, which is what generates the blurred image.

This is worth thinking about for a moment, because it is unusual for a shell extension to need an external image processing program installed system-wide. The probable reason is that the blur is computed once, at build or install time, rather than on every keystroke, and doing that in JavaScript against a screenshot would be far slower than handing the job to a tool that already does it well. The trade is a machine without ImageMagick gets no blurred background, and the README's phrasing, which requires it for the feature, suggests it is not optional within that feature.

The credit line confirms the provenance. The README credits Blur-My-Shell for the background blurring code, which is a separate GNOME extension that does exactly this and does it well. Reusing that code rather than writing it is the right call, and it also means you can look at how the effect is achieved elsewhere if the behaviour is unclear.

The other customisation options, colours, background and borders, are pure GNOME Shell theming and carry no external dependency. The extension has a stylesheet.css at the root and a style.js module in the tree, plus a preferences directory and a schemas directory, which is the standard GNOME Shell extension layout: GSettings schemas for preferences, a JavaScript preferences UI, and a stylesheet for the theme.

The primary language is JavaScript, which is what GNOME Shell extensions are written in, and the repository includes an.eslintrc.yml and a lint/ directory, so the JavaScript is linted.

The Makefile shows how the extension is built and where it lands

Installation from source is a clone and a make, and the Makefile is where the details live.

$ git clone https://github.com/icedman/search-light
$ cd search-light
$ make

The default target is all, which runs build, install and lint in that order. The build step compiles the GSettings schemas with glib-compile-schemas in strict mode into the schemas directory, and strict mode is worth noting because it makes the schema compiler fail on anything invalid rather than warn.

The install step creates the extension directory in your home directory and copies the project into it, using the extension identifier [email protected] and the per-user extension directory that GNOME Shell reads.

The directory name is the extension identifier, [email protected], and the path is the per-user extension directory that GNOME Shell reads. Installing per user rather than system wide means you need no root and you can remove it by deleting one directory, which is a good property for an extension that is still on testing branches for recent GNOME versions.

There is also a publish target that assembles a build directory and zips it into [email protected], with an install-zip target that unzips that archive into the same extension path. The publish target copies only the files that matter, the JavaScript, metadata, stylesheet, the ui, preferences, effects and apps directories, the schemas and the documentation, and it deletes the files that only make sense during development, the dev-only prefixed files, utils.js, drawing.js, chamfer.js and the imports_ modules. The g44 target builds a different variant, running a transpile.py script and copying the desktop files for the apps directory instead of the whole tree.

The apps directory and the presence of desktop files in the g44 target indicate that the extension contributes application entries, which is how it can offer a search for installed applications at all.

Installing from the Extensions repository instead

Most people will not need the Makefile at all. The extension is published on the GNOME Extensions Repository, and the README points at the listing directly, so the practical installation path is the Extensions app on the desktop, or the website, where the extension is listed and can be installed and updated alongside everything else you have installed that way.

The trade between the two paths is straightforward. The Extensions repository gives you updates through the same channel as your other extensions, and it gives the author a way to publish a new version without you rebuilding anything. The Makefile gives you a specific branch, which is what you need when your GNOME version is not the one the main branch targets, and it gives you the ability to change the code, which matters if you are porting it to a version the author has not finished.

Given the branch structure described in the Notice, most users on recent GNOME will want the repository listing, and users on 44 and prior or on a testing port will want the Makefile with the matching branch.

The repository also carries a Buy Me a Coffee badge for the author and a contributors badge, and the licence is GPL-3.0 with a LICENSE file at the root, copied into the build directory by the publish target so that the distributed zip carries it. There are no GitHub releases, so the version history of the extension is in the CHANGELOG.md and on the Extensions repository rather than in release tags, and the last push to the repository was on 2026-05-09.

Editorial conclusion

Adopt search-light if you use GNOME Shell and find the Overview too slow or too heavy for the common case of launching an application, and if you are willing to install ImageMagick for the blurred background option. Do not adopt it if you rely on the Overview for workspace switching, since the extension's whole point is to take the search widget out of it, and check the branch mapping before you install because support is split across GNOME generations. Before you commit, read the Notice section in the repository, pick the branch that matches your GNOME version, build and install with the Makefile, and verify the Ctrl+Cmd+Space keybinding does not collide with something already in your desktop's shortcut list.

Frequently asked questions

Official sources

1. icedman/search-light on GitHub
2. Issues
3. License: GPL-3.0
4. README