QTerminal: a small Qt terminal emulator with tabs, bookmarks and a clean build recipe

What problem QTerminal solves on a Qt desktop

QTerminal is described as a lightweight Qt terminal emulator, and the interesting part of that sentence is the adjective. A terminal emulator is one of the oldest GUI programs and there is no shortage of them, so the value of a new one has to be narrower than the feature list.

The niche is a Qt desktop. On a machine already running KDE, GNOME, Cinnamon or LXQt, a terminal that draws with the same toolkit inherits the same look, the same font handling and the same dialog style, and it does not drag a second GUI stack onto the system. QTerminal is the LXQt project's own terminal, but it is deliberately not bound to LXQt. The README states that it is maintained by the LXQt project but can be used independently from this desktop environment, and that the only bonds are lxqt-build-tools, which is a build dependency rather than a runtime one.

That separation matters in practice. An LXQt user installs it from the same place as everything else, and a user on another Qt desktop installs the same binary without inheriting a desktop environment. What they get is a tabbed terminal with a bookmarks pane, as the screenshot in the repository shows, with the terminal emulation itself delegated to a separate widget library.

The audience is therefore people who want a small, conventional terminal that behaves like the rest of their desktop rather than a programmable multiplexer with a plugin ecosystem. If you are after scripting, panes and session persistence, this is not that tool, and the project does not pretend otherwise.

The terminal engine lives in QTermWidget, not in QTerminal

QTerminal is a lightweight Qt terminal emulator based on QTermWidget. The division of labour is the whole architecture: QTermWidget is a separate repository under the same LXQt organisation and provides the terminal widget itself, the part that talks to a pseudo terminal, draws the characters and handles the escape sequences, while QTerminal is the application shell around it.

What that means for an adopter is that the emulation behaviour you experience is QTermWidget's, and QTerminal inherits it. When a rendering bug appears in a specific escape sequence or a font quirk, the fix belongs in the other project. Conversely, the things QTerminal does own are the window, the tab bar, the bookmarks list and the session handling, and those are the parts visible in the repository's own screenshot with three tabs open and a bookmarks pane beside them.

The repository layout supports this reading. The top level holds a src directory and a test directory, a single CMakeLists.txt, two desktop entry templates named qterminal.desktop.in and qterminal-drop.desktop.in, an AppStream metadata file, a Doxyfile for documentation generation, a CHANGELOG, and a sample bookmarks file called qterminal_bookmarks_example.xml. The two desktop entry files and the metainfo file are what let the application appear in a desktop menu with the right icon and a translated description.

The example bookmarks file is a small but telling artefact. It tells you bookmarks are a first-class, persisted, shareable concept in this application, and that the format is documented by example rather than by specification.

Building from source: Qt 6.6, CMake 3.18 and an out-of-source build

The build instructions are compact, and every requirement is named. The dependencies are Qt at version 6.6.0 or newer and QTermWidget. libcanberra is optional and exists so the terminal can play bells. Building also needs CMake at version 3.18.0 or newer and lxqt-build-tools, plus optionally Git to pull the latest VCS checkouts. Configuration is handled by CMake, building out of source is required, and the CMake variable `CMAKE_INSTALL_PREFIX` will normally have to be set to `/usr`.

The sequence itself is the usual GNU one. The README says to build run `make`, to install `make install` which accepts variable `DESTDIR` as usual, and the code configuration step is a plain CMake invocation. Because the configuration is driven by CMake variables rather than by a bespoke script, a distribution packager can override the install prefix and the destination directory without patching anything.

Two details decide whether your build attempt succeeds. The first is the Qt floor: version 6.6.0 or newer, so a distribution still on Qt 6.5 or 6.2 has to package an older tag. The second is the out-of-source requirement, which is not a suggestion. An in-tree build pollutes the source directory and, given that the project also pulls VCS checkouts for some dependencies, mixing build output with fetched sources is a reliable way to confuse a later `make clean`.

If you only want to run the program rather than develop it, the source route is the wrong one. The next section covers the packaged path.

Binary packages exist for the major distributions

Official binary packages are provided by all major Linux and BSD distributions, and the instruction to users is simply to search for the string `qterminal` in their package manager. That is the shortest path to a working install, and for most people it is the only sensible one.

The wording matters. The README calls these official binary packages, and the project is part of the LXQt organisation, so the packaging in the major distributions is first party rather than a third-party build. What this does not tell you is which version each distribution currently ships. A distribution that packaged 2.2.1 in 2025 and one that packaged 2.4.0 in 2026 will give you noticeably different applications, and the repository's release history shows why the difference matters: version 2.2.1 was published on 2025-05-05, version 2.3.0 on 2025-11-05 and version 2.4.0 on 2026-04-20.

So the practical check before you adopt is the version in your own package manager, not the version on the project page. If the distribution build is several minor versions behind, the gap is where bug fixes and any new configuration options live.

The build dependency picture is also friendly for packagers. Because QTerminal is usable independently of LXQt, a distribution can package it without shipping the rest of the desktop environment, and the README is explicit that the only external tie is the build tooling.

Translations run through LXQt-Weblate, and the repo carries the plumbing

Translation is handled on the LXQt Weblate instance, where the project has its own page under the lxqt-desktop group. That is a normal arrangement for a desktop project with many small applications, and it means translators do not need to clone the repository or build anything to contribute a string.

The repository supports that workflow with a small set of files. There is a .translation-update entry, the standard Weblate hook that pushes new source strings to the translation platform, and a .ci directory alongside .github for the automation around it. The l10n handling is not described in the README, so the exact workflow for pulling translations back into a build is not documented there, and anyone packaging from source will need to consult the LXQt build tooling convention.

The screenshot naming convention adds one more piece of information. The desktop entry templates use the .in extension, meaning their contents are substituted by CMake at configure time, which is how the installed application gets the right icon paths and the right application name for the user's locale. The AppStream metainfo file follows the same pattern, and it is what software centres read to build the application listing.

Taken together, these files show the project is built for distribution rather than for a single developer machine. The Doxyfile at the root and the CHANGELOG suggest the same attention to the parts of a project that are read by other people.

GPLv2, a three-release history and a busy master branch

The licence is GPLv2 or any later version, and the README points to the LICENSE file for the full text. This is a factual reading of the identifier rather than legal advice, but the practical point for a packager is that the or-later clause allows the code to be redistributed under GPLv2 or under a later version of the licence, which gives a distributor a choice of terms. A downstream project that links against QTerminal and distributes the result will have its own obligations to check.

Activity is not in question. The last push to the master branch was on 2026-10-18, and the three most recent releases are 2.4.0 from 2026-04-20, 2.3.0 from 2025-11-05 and 2.2.1 from 2025-05-05. The gap between the newest tag and the last commit is where the current work sits, which is normal for a project that tags releases for distribution and keeps developing on the default branch.

For someone choosing a terminal emulator, the honest assessment is that this is a small, actively worked-on C++ project with a modest feature set, released on a roughly twice-yearly cadence by the LXQt project. That is a different proposition from a terminal emulator with a large third-party extension ecosystem, and for a straightforward tabbed terminal with bookmarks on a Qt desktop, the smaller surface is the point rather than a limitation.

Editorial conclusion

QTerminal is a sensible pick for a Qt based desktop, especially one already running LXQt, and for anyone who wants a terminal with tabs and bookmarks without pulling in a large terminal multiplexer. It is a poor fit if you need to build from source on a machine without Qt 6.6 and CMake 3.18, since there is no prebuilt path outside your distribution's package manager, and it is the wrong choice for a non-Qt desktop where the extra Qt runtime is pure overhead. Before committing, read the CHANGELOG file in the repository and compare it against the release you currently run, since version 2.4.0 was published on 2026-04-20 and the last push to master was on 2026-10-18, so the gap between tagged releases and trunk is where the recent work sits.

Frequently asked questions

Official sources

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