Fly-Pie: a pie menu for GNOME Shell, opened from the keyboard

A pie menu that opens from a shortcut

Fly-Pie is an extension for GNOME Shell which lets you open marking menus via keyboard shortcuts. You can use it to launch applications, simulate hotkeys, open URLs and much more.

A marking menu is the radial interface that appears when you press a key: a circle of wedges, each labelled with an action, and you select one by moving towards it. The interesting part of Fly-Pie is that it does not force you to use the gesture. The README lists the three alternative selection modes you can seamlessly transition between once a marking menu is open.

Point-and-Click is the first, and it selects items by clicking on them or anywhere in the corresponding wedges. Marking-Mode selects items by drawing gestures, where you click anywhere and drag your mouse, and pausing or making a turn selects the currently dragged item. Turbo-Mode lets you draw gestures while holding Ctrl, Shift or Alt without having to press your mouse button, which the README singles out as especially useful when you opened the menu with a shortcut involving such a modifier.

That last mode is the cleverest of the three, because it resolves a real conflict in this kind of interface. If the shortcut that opens the menu already uses a modifier, you cannot use that modifier to switch selection modes, and Turbo-Mode works around it by letting the other modifiers stay free for mode switching.

Installation is from the GNOME extensions site, and after installation you open the example menu by pressing Ctrl and Space together.

Designed for a mouse, and honest about it

The README has a section asking whether you will love Fly-Pie, and it answers with a design constraint rather than a promise. Fly-Pie is designed for you if you have one hand at the mouse most of the time. It is not designed to be used with a keyboard only, and the README says there are other applications which work better in that case, naming kupfer as an example.

That is a more useful statement than a feature list, because a marking menu and a keyboard-driven launcher solve overlapping problems for different people. A pie menu is fast when your hand is already on a pointing device and the menu is small. It is slow when you have to move your hand to the mouse first, and a launcher that takes a typed prefix is faster in that case. Fly-Pie declines to serve that user.

The other side of the same point is touch. The README says Fly-Pie also works nicely with touch input, which follows from the design rather than being a separate implementation. Gesture selection and tap selection are the same mechanism seen from a finger, and a wedge hit test is a wedge hit test.

The three modes also matter for accessibility and habit. Someone who tries the gesture once and does not like it can fall back to clicking a wedge, and someone who cannot draw a clean gesture can still use the menu. The interface degrades towards the slower mode rather than failing.

Low maintenance mode, with the successor already named

The most important line in the README is the notice at the top: Fly-Pie is currently in low-maintenance mode as the author is working on his follow-up project Kando.

That statement changes how you should read everything else in the repository, including the release list. The recent releases are v31 from 2025-09-21, v32 from 2025-11-23 and v33 from 2026-03-15, and the last push to the repository was on 2026-09-29. So the code is being touched, and the version numbers are still moving, but the effort behind them is smaller than it was.

The practical consequence is a choice between two paths. If you are installing Fly-Pie today, you are adopting a stable, released extension that will keep working on the GNOME version it supports, and you should expect new GNOME releases to be a risk, because a shell extension that touches internal APIs has to be ported when those APIs change. If you are looking for a project to follow or contribute to, the author has told you where the energy is going, and the sensible thing is to look at Kando before investing an evening in Fly-Pie.

That is not a criticism of the project. It is a maintainer being explicit, which is more useful than an abandoned repository with a cheerful README. The low-maintenance notice is at the top of the file rather than in a changelog, and the changelog document is linked from the README for anyone who wants the detail.

Building and installing it with make and gnome-extensions

The Makefile in the repository is where the packaging story lives, and it is written to be portable to other extensions, with the name and domain defined at the top so the rest of the file does not hard code them.

Five recipes can be invoked by the user. The zip recipe only bundles the extension without installing it. The install recipe creates the extension zip and installs it, the uninstall recipe removes the previously installed extension, pot generates a translation template file with gettext, and clean removes the temporary files.

The install step is the one worth quoting, because the shell restart is part of it:

make install
gnome-extensions uninstall "[email protected]"

The install recipe runs gnome-extensions install with the built zip and the force flag, then echoes that the extension was installed successfully and that you should now restart the Shell, with the Alt and F2 combination and then r. That last part is not a suggestion. A GNOME Shell extension is loaded into the running shell process, so a fresh login or a shell restart is what makes the extension appear, and that is exactly the kind of step people skip and then conclude the install failed.

The translation template recipe is a gettext xgettext call over the JavaScript and the UI files, with the copyright holder set to the author and the package name set to the extension name, producing po/flypie.pot. The locales are compiled from the po directory into a locale directory inside the zip, which is how the translations reach the installed extension.

Schemas, presets and a D-Bus interface

The repository layout shows what a shell extension of this kind has to carry, and it is worth reading as a checklist for anyone building one.

There is extension.js and prefs.js at the top level, metadata.json for the extension's own description, and then the directories: src for the code, schemas for the GSettings schema, presets for the bundled menu definitions, resources for the compiled gresource bundle, po for the translations, assets, docs and scripts, and tests. The zip content list in the Makefile names exactly which of these go into the published archive: the JavaScript files, the compiled locale files, the gresource bundle, the gschema XML under schemas/, the presets, metadata.json and the LICENSE.

The docs directory is the part that makes this a project rather than a script. There is a usage guide called the first steps document, a document on the D-Bus interface, one on the software architecture, and two that matter if you want to extend it, one on creating new action types and one on creating new menu types. Separate documents for actions and menus tell you the design separates what a menu item does from what the menu is, which is the same split you would want for a plugin architecture.

There is also a translating document and a Weblate badge, which means the translations are handled on a platform rather than in pull requests, and a release management document and a continuous integration document for the process side. The project is small, but the paperwork around a shell extension that has to survive GNOME releases is not.

The code is MIT, the README is CC-BY-4.0, and REUSE tracks the rest

The licence needs a sentence of care, because the repository does not use one blanket licence.

The SPDX header at the top of the README states that the file is licensed under CC-BY-4.0, while the Makefile's own header says MIT, and the repository's licence metadata says MIT as well. The presence of a .reuse directory and a LICENSES directory points to the reason: the project uses the REUSE specification, which requires every file to carry its own licence information, so the documentation and the code can carry different terms and both can be stated precisely.

The practical reading is that the code is MIT and the prose is Creative Commons Attribution 4.0, and both are permissive. A corporate use that requires a single licence across the whole tree will need to look at the LICENSES directory rather than the badge.

The attribution side of CC-BY has one consequence worth knowing. If you quote the README text, or reuse the documentation images such as the banner and the player screenshots, you owe attribution, and the same is true of the example menu assets if you redistribute them.

The project also lists sponsorship links in four forms, Ko-fi, GitHub, PayPal and cryptocurrency, and keeps a page of people who have already donated. For a project in low-maintenance mode, that is a reasonable way for the author to keep the lights on, and it is also a signal that the maintenance that does happen is partly funded rather than accidental.

Editorial conclusion

Fly-Pie fits a GNOME user who reaches for the mouse with one hand and wants a keyboard shortcut to open a radial menu of applications, hotkeys and URLs, and who is willing to install a shell extension and restart the Shell. It does not fit a keyboard-only user, since the README says plainly that it is not designed for that case and points elsewhere instead. Before you install it, check the GNOME version your distribution ships, and read the installation document rather than the README, because the README's own note says the project is in low-maintenance mode with a successor already under way.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Schneegans/Fly-Pie on GitHub