Falkon: the KDE browser built on QtWebEngine, and what its build files tell you

What Falkon is, and the gap it fills

Falkon is a KDE web browser that uses the QtWebEngine rendering engine. That single sentence from the README defines the project more precisely than any feature list: it is a browser shell around Chromium's engine as packaged by Qt, with KDE's desktop integration layered on top. The people it serves are narrow but real. If you run a KDE desktop and want a browser that is not Firefox or Chrome, Falkon is the one KDE ships and maintains. If you are building a Qt application or an embedded image and need a browser component that shares your toolkit, Falkon's dependency graph is the same one you already have. The repository layout confirms the scope: src/ holds the browser, themes/ holds UI themes, po/ and poqm/ hold translations, and linux/, mac/ and snapcraft.yaml plus .flatpak-manifest.json cover packaging for three distribution routes. This is not a project trying to replace Chrome for a general audience. It is a KDE application, and it is honest about that.

How the QtWebEngine shell is put together

The architecture is a Qt application with QtWebEngine at the core. Page rendering, JavaScript execution and network fetching happen inside QtWebEngine; Falkon supplies the window, tabs, bookmarks, history, download handling and the extension host around it. Two directories make the split visible. src/ is the browser itself. autotests/ and tests/ sit beside it, which tells you the project carries automated tests rather than relying only on manual checks. The build system is CMake, driven by CMakeLists.txt at the top level and config.h.cmake for generated configuration. The presence of .gitlab-ci.yml and .kde-ci.yml means builds run through KDE's own continuous integration rather than a third-party service, so the CI configuration and the review workflow live in the same infrastructure. Code review happens on Phabricator, and the README instructs patch authors to add #Falkon as a reviewer. Bugs go to KDE Bugzilla under the Falkon product. That is the full contribution path: Phabricator for code, Bugzilla for issues, a mailing list and the #falkon channel on irc.libera.chat for discussion.

Installing Falkon: download or build from source

The README does not contain installation instructions. It states that downloads are available from the homepage at falkon.org/download, and that is where a packaged install begins. Everything the README documents is the source build, so the commands below are the ones it gives. Create a build directory, configure with CMake, then compile and install:

mkdir build && cd build
cmake ..
make && make install

Running those three lines in sequence produces a configured build tree, then a compiled and installed binary. The README does not list required Qt or QtWebEngine versions, so a configure failure is the point at which you discover what your system is missing. If you are installing somewhere other than a system prefix, the README gives a second form. Set the install prefix at configure time, then point XDG_DATA_DIRS at the custom share directory before launching:

cmake -DCMAKE_INSTALL_PREFIX=$HOME/falkon
export XDG_DATA_DIRS="$HOME/falkon/share:$XDG_DATA_DIRS"
$HOME/falkon/bin/falkon

The XDG_DATA_DIRS line is the part people miss. Without it the binary starts but does not find the resources installed under the custom prefix. The README also notes that when installing to a custom prefix you may need to adjust that variable, which is the closest the documentation comes to describing a first-run problem. For a packaged install, the alternative routes visible in the repository are the Flatpak manifest and snapcraft.yaml, and both are files in the tree rather than instructions in the README.

Where Falkon is the wrong choice

The README is thin, and that thinness is a real cost. There is no documented upgrade procedure, no rollback path, no list of supported Qt versions and no extension development guide, even though the Bugzilla component list includes an extensions component. If your team needs a browser with a documented release cadence and a supported migration path between versions, this repository does not provide one, and the absence is not something you can work around by reading harder. There is also a licensing constraint worth understanding before you embed anything. Falkon is GPL-3.0. If you plan to ship it inside a product, or to link its code into a proprietary application, the GPL-3.0 terms apply to that distribution. That is a statement about the licence identifier in the repository, not legal advice; if the distinction matters to your product, it is a question for your own counsel. Finally, because rendering comes from QtWebEngine, Falkon inherits the engine's behaviour and its update cycle. A site that breaks in QtWebEngine breaks in Falkon, and Falkon's maintainers cannot fix that upstream.

Falkon compared with a KDE-adjacent alternative

The obvious comparison is Konqueror, the other KDE browser, and the difference is architectural rather than cosmetic. Konqueror is built around KDE's own KPart component framework, where the browser is assembled from pluggable parts and the rendering engine can be swapped. Falkon takes the opposite approach: it commits to QtWebEngine as a single rendering engine and builds a conventional browser application on top. That choice buys modern web compatibility, because QtWebEngine tracks Chromium, and it costs flexibility, because there is no part architecture to extend and no second engine to fall back on. For a developer, the practical consequence is where extension work happens. Falkon extensions run inside the QtWebEngine-based application rather than through KDE's KPart plugin mechanism. If your existing tooling targets KParts, it will not transfer. If your tooling targets Qt and QtWebEngine, it moves across more easily.

Maintenance, releases and what the repository shows

The repository is not archived, and no last push date is given, so there is no basis for describing how frequently it is updated. What the tree does show is a maintained release process: a CHANGELOG file, translation directories, packaging manifests for Flatpak and Snap, and CI configuration for both GitLab and KDE's own infrastructure. Those files exist because releases are produced, not because someone set them up once. The upgrade cost for a source build is the ordinary one for a Qt application: re-run the CMake configure and rebuild, and expect to resolve dependency changes when Qt or QtWebEngine moves. The README documents no migration steps between versions, so CHANGELOG is the file to read before upgrading rather than after. For packaged installs, upgrade cost is whatever your distribution's package manager does, which is outside the project's control. The licence is GPL-3.0, and COPYING sits at the top level of the repository alongside the source.

Editorial conclusion

Adopt Falkon if you want a QtWebEngine browser that follows KDE packaging and desktop conventions, or if you are maintaining a KDE-based image and need a browser that builds with CMake against Qt. Do not adopt it expecting the README to walk you through installation, extension development or a supported upgrade path, because it does not. Before committing, check the download page at falkon.org for a package for your distribution, read CHANGELOG in the repository for what changed between releases, and confirm which Qt and QtWebEngine versions your distribution ships, since the README names no minimum.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository