Geany: what the lightweight GTK IDE actually gives you

The gap Geany was written to fill

Geany targets a specific kind of developer: someone who wants syntax highlighting, code completion, folding and a symbol list without pulling in a desktop stack. The README states the goal plainly, a small and fast IDE with few dependencies from other packages, and independence from a particular desktop environment. It uses only the GTK+ toolkit, so the GTK runtime libraries are enough to run it.

That constraint shapes everything else. There is no project file format to learn, no workspace indexer running in the background, and no language server requirement. The supported filetypes listed in the README are C, Java, PHP, HTML, Python, Perl and Pascal, and the feature list adds call tips, auto completion of constructs like if, for and while, auto completion of XML and HTML tags, an embedded terminal emulation, and extensibility through plugins. If your work is editing a handful of files in one of those languages, the feature set maps directly onto it. If your work is a monorepo with a build graph, it does not.

How Geany is put together: GTK, Scintilla, ctags, plugins

The repository layout tells you most of the architecture before you read any source. Geany is written in C. The top level contains src/, plugins/, scintilla/, ctags/, data/, doc/ and po/. Scintilla is the editing component, and the README notes it is an included library with its own license file at scintilla/License.txt. ctags supplies the symbol information behind the symbol lists. po/ holds the translations, which is consistent with the gettext requirement in the build instructions.

The data flow is conventional for this class of editor. Scintilla renders and edits the buffer, the ctags-derived index feeds the symbol list and completion, and plugins extend the application through the plugin API rather than through a separate process. The build system reflects that split: meson_options.txt exposes selectable features that reduce build and runtime dependencies, and the README gives the example of turning off the VTE terminal with a configure flag, which would remove the embedded terminal emulation from the build.

One detail worth noticing is the presence of both meson.build and configure.ac at the top level. The README is explicit that Meson support is incomplete and a work-in-progress, while the Autotools path is the one described in full for release tarballs. Anyone packaging Geany or building it in CI should read that sentence before choosing a build system.

Installing Geany from distribution packages

The README calls distribution packages on Linux, BSD and similar distributions the easiest and recommended way, and notes you also get automatic updates through the package manager. Packages exist for most distributions including Debian, Fedora and Ubuntu. The exact package name is not given in the README, so use your distribution's search rather than a command copied from here.

On macOS and Windows, the README points to https://www.geany.org for prebuilt binary packages. Building from source on those two platforms is described as more complicated and out of scope of the README, which directs readers to the wiki at https://wiki.geany.org/howtos/. That is a real boundary: if you are on Windows and want a custom build, the README will not walk you through it.

For a source build from a release tarball, the README gives three commands in sequence. Run them from the unpacked tarball directory, and expect configure to fail loudly if GTK3 development headers are missing.

./configure
make
make install

Building from a Git clone is a different path. The README says you need Autotools (autopoint, automake, autoconf and libtool), gettext and the GLib development files before running anything, plus rst2html from Docutils. The first step is the autogen script, after which you follow the release tarball instructions.

./autogen.sh

If you prefer Meson, the README states it requires a separate build directory and gives both a one-line and a manual form. The prefix defaults to /usr/local and can be changed at configuration time.

meson build
meson compile -C build
meson install -C build

Your first real session, from the command line

The README's usage section is short. To start Geany, type the binary name in a console, or launch it from your desktop environment's applications menu.

geany

The option the README singles out as probably the most important is the configuration directory flag, which lets you point Geany at an alternate config directory instead of the default. That matters when you want a clean profile, or separate profiles for different projects, without touching your normal settings.

geany -c

For anything else, the README directs you to the manual page or to the built-in help output, which is the authoritative list of flags rather than anything inferred here.

geany --help

Once the window is open, the features you will actually notice first are the symbol list, folding and completion, all of which depend on the filetype Geany detects for the file you open. If you are working in C, Python or one of the other listed filetypes, the symbol list populates from the ctags index. If you open a file in a language outside the supported set, you get plain text editing and none of that machinery, which is the honest limit of a filetype-driven editor.

Where Geany is the wrong tool

The README does not document a debugger, a version control client, refactoring operations, remote development over SSH, or a language server protocol client. None of those appear in the feature list. If your workflow depends on them, Geany is not a smaller version of what you already use; it is a different category of program, and you will spend your time bolting on what is missing.

The plugin system is the intended answer to extensibility, but the README says only that extensibility exists through plugins and does not enumerate them, describe how to install them, or state which platforms they ship for. That silence is worth taking seriously if a plugin is the reason you are considering Geany. Verify plugin availability for your platform before you plan around it.

There is also a build-time trade-off hiding in the options. Features can be disabled to reduce dependencies, and the README's example removes VTE, which means the embedded terminal goes away. A minimal build is leaner, but it is also a different program from the one the feature list describes. Distributions make that choice for you, so a package named Geany on one system may not have the same capabilities as on another.

Geany against a full editor such as VS Code

The comparison people actually search for is Geany versus VS Code, and the difference is architectural rather than a matter of taste. VS Code is built around an extension host and, in practice, around language servers that run as separate processes and index your project. Geany is built around GTK, Scintilla and ctags compiled into a single application with a plugin API.

That produces opposite failure modes. A language-server editor gives you cross-file navigation, diagnostics and refactoring, at the cost of memory, startup time and a per-language server to configure. Geany gives you a fast start and a small dependency footprint, at the cost of project-wide intelligence. The README's feature list is a fair summary of the second position: highlighting, completion, call tips, folding, symbol lists, terminal emulation, plugins.

Against Notepad++ the split is platform, not architecture. Both are lightweight editors with a plugin model, and the search results show people asking whether Geany is the better choice. The README gives you no basis for that judgement beyond the GTK dependency and the cross-platform binary packages it points to; decide it by opening your own files in each.

Maintenance, licensing and what upgrades cost you

The repository is not archived, and the last push was on 2026-09-14. Releases are infrequent but not stalled: 2.1.0 on 2025-07-06, 2.0.0 on 2023-10-19, and 1.38.0 on 2021-10-09. That cadence is typical of a mature C application, and it means you should not expect a steady stream of new features between releases. Plan upgrades around release announcements rather than assuming continuous change.

Geany is distributed under the GNU General Public License, version 2 or, at your option, any later version, with a copy in the COPYING file. The bundled Scintilla library has its own license in scintilla/License.txt, which is separate from Geany's. If you redistribute Geany or build a product around it, read both files; the dual-license structure is the kind of detail that gets missed when people assume the top-level license covers everything in the tree. This is a description of what the repository states, not legal advice.

Upgrade cost is low in the ordinary case, since distribution packages handle it. The cost that is easy to underestimate is configuration drift: if you have customized settings, the config directory flag is your escape hatch for testing a new version against a copy of your profile before replacing the real one.

Editorial conclusion

Adopt Geany if you want a GTK editor with symbol lists, folding and a plugin API that starts instantly on modest hardware, and if your language is covered by its built-in filetype support. Do not adopt it if you need a full project model with refactoring, remote development or a debugger built in; the README lists none of those. Before committing, check that your distribution ships a current package or that you can build against GTK3, and confirm the plugin you rely on is packaged for your platform, since plugin availability is not documented in the README.

Frequently asked questions

Official sources

1. geany/geany on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases