Fluid: a Material Design component set for QtQuick, built on the Liri desktop stack

A control set for QtQuick, not a toolkit

Fluid is a collection of cross-platform QtQuick components for building fluid and dynamic applications, using the Material Design guidelines, and the online documentation is at docs.liri.io.

The name of the project family is Liri, and the topic list on the repository includes convergence, wayland, linux, macos, windows and android, which is the shape of the desktop stack the components are designed for. The components themselves are QML, with the primary language of the repository being QML, and there is a src/ directory holding the component code, a tests/ directory, a doc/ directory for the documentation sources, and an assets/ directory.

What Fluid is not is a Qt version. It is a set of controls, in the Material Design idiom, that you drop into a QtQuick application. That distinction matters because the alternative to using it is designing your own button, switch, text field and dialog set, which is a lot of visual design work for a team whose interest is elsewhere.

The licensing is a case worth reading carefully, because the repository metadata and the README do not match at first glance. The licence field on the repository says Other, a custom licence GitHub cannot classify, and the tree contains two licence files, LICENSE.FDL and LICENSE.MPL2, with the README stating that the project is licensed under the terms of the Mozilla Public License version 2.0 and the badge in the README header pointing at the MPL 2.0. The FDL in the file name is the Free Document License, and the presence of both files is the standard pattern for a project that licences its documentation separately from its code. This review does not interpret licence terms, and the practical advice is to read both files in the repository root and see which one covers the files you intend to use.

The homepage is the documentation site, and the README is short, which for a component library is a sign that the real content lives in the docs rather than in the repository.

Qt 6.12, Wayland, and a specific list of Qt modules

The dependency list is precise, and it is the first thing to check.

Qt >= 6.12.0 is required, with at least these modules: qtbase, qtdeclarative, qtquickcontrols2, qtgraphicaleffects and qtsvg. On Linux you also need wayland >= 1.15 and qtwayland, and cmake >= 3.25.0 is required.

Two of these deserve a comment. The qtgraphicaleffects module is a Qt Quick module that was deprecated in Qt 6.8, so a library that still depends on it is pinned to a range of Qt versions where that module exists and works. And the wayland requirement with a minimum of 1.15 alongside qtwayland tells you that the Linux experience this project targets is the Wayland session, which fits the rest of the topic list, where wayland and convergence sit next to the platform names.

The version floors have a reason behind the wayland and cmake numbers. The README notes that if cmake-shared is not installed and -DFLUID_USE_SYSTEM_LCS:BOOL=ON is passed to cmake, the build will fail without finding LiriSetup. LiriCMakeShared is the shared build infrastructure of the Liri stack, and the -DFLUID_USE_SYSTEM_LCS flag selects whether to use a system-wide copy of it rather than the vendored submodule. In other words, the default build is self-contained through git submodules, and the flag is for packagers who already provide the shared macros system-wide.

That is the sort of dependency a distro packager cares about and an application developer mostly does not, which is why the README splits installation into a system-wide path and a per-project path, and why the system-wide path comes with the warning that it is discouraged in most cases because there is a risk to pollute the system with libraries not managed by a package manager.

Building from the command line, and the four CMake switches

The build instructions are short, and the four options are the interesting part.

From the root of the repository, the sequence is a submodule update, a build directory, a cmake configure with an install prefix, then make and make install:

git submodule update --init
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/path/to/prefix ..
make
make install # use sudo if necessary

The README notes that you should replace /path/to/prefix with your installation prefix, and that the default is /usr/local. The submodule update matters because the build depends on the Liri shared CMake macros being present.

The four options are appended to the cmake command, and each of them turns something off or on that changes what gets built:

- -DFLUID_USE_SYSTEM_LCS:BOOL=ON uses a system-wide copy of LiriCMakeShared. - -DFLUID_WITH_DOCUMENTATION:BOOL=ON builds the Doxygen documentation. - -DFLUID_WITH_DEMO:BOOL=OFF does not build the demo application. - -DFLUID_WITH_QML_MODULES:BOOL=OFF does not build QML modules.

The last two are the ones to notice. A build with the QML modules disabled does not produce the QML modules, which are presumably how the components are consumed at runtime, so a distribution package that wants them enabled will want the default. The demo application is the thing you would turn off for a release build.

There is also a standalone path: you can perform a standalone build by opening CMakeLists.txt with QtCreator, provided cmake is set up correctly, and the README points at a guide for configuring the same cmake arguments in QtCreator's build settings.

The documentation build has its own prerequisites. The HTML documentation is built when the documentation option is on, and Doxygen and doxyqml are required for that. The generated files are installed into <prefix>/share/doc/fluid/html, and you open <prefix>/share/doc/fluid/html/index.html with a browser to read them.

Two installation models, and why the system-wide one is discouraged

The README offers a choice that most component libraries do not, and the reasoning is worth taking seriously.

You can either install system-wide or do a per-project installation, which is essentially embedding Fluid in your project. The two audiences are named directly. System-wide installations are usually performed by packagers who want to redistribute Fluid in their Linux distribution. Per-project installation is most useful for mobile developers that want to build Fluid alongside their project.

The system-wide path is the same four commands with a different prefix, and it ends with a sudo make install:

git submodule update --init --recursive
mkdir build
cmake -DCMAKE_INSTALL_PREFIX=/usr ..
make
sudo make install

Note the difference in the submodule flags. The system-wide instructions use --init --recursive while the general build instructions use only --init, which is a small inconsistency in the documentation and one to be aware of if the recursive fetch matters for your checkout.

The system-wide path also assumes a layout. The README says it assumes that your distro installs QtQuick modules in /usr/lib/qt/qml like Arch Linux does, and asks you to change the paths for your distribution, noting that the same goes for other operating systems.

The warning attached to that path is the part to remember: a system-wide installation is discouraged in most cases because there is a risk to pollute the system with libraries not managed by a package manager. If you are not a packager, you are being told not to run sudo make install on your workstation, and the per-project route exists precisely so you do not have to.

For the per-project route, the repository carries three worked examples: examples/perproject/minimalqmake, examples/perproject/minimalqbs and examples/perproject/minimalcmake. Three build systems, three minimal projects. That is a strong signal about who the audience is, since anyone arriving with their own build system can start from the closest example rather than from the documentation.

git flow, the develop branch, and a release that stopped in 2023

The maintenance story is the most important thing to know about this project, and the README is upfront about it.

The project develops using the git flow method, and the consequence is stated directly: the develop branch contains code that is being developed and might break from time to time. If you want a stable version, install one of the releases or clone the master branch, which has the latest released version.

So there are two tracks, and you have to pick one deliberately. develop is where the work is, and it is not stable by construction. master is the released line.

The dates on those two tracks are very different. The default branch is develop, and the last push was on 2026-10-14, so the work is current. But the recent releases are v1.3.0 from 2023-11-10, v1.2.0 from 2019-08-02 and v1.1.0 from 2018-10-28, so the last tagged release is more than two years old.

That gap is the thing to weigh. The project is alive in the sense that commits land on develop, and the recent push is within a week of this review. It is not a project with a 2026 release. Anyone taking the master branch gets the 1.3.0 code line, and anyone tracking develop gets unreleased work whose stability is disclaimed in the README itself.

The repository is not archived, so nothing has been formally wound down. The CI badge points at a workflow running on the develop branch, and the top-level tree shows the tooling around it: a .devcontainer/ directory, .clang-format for the C++ sources, a .tag file, an .agents/ directory alongside .claude/ and .codex/ directories and an AGENTS.md and CLAUDE.md, a skills-lock.json, a features.cmake at the root, a cmake/ directory of build modules, and tests/. The .agents/ and .claude/ directories suggest the project has been set up for coding agents to work in, which is consistent with a project that is still being developed on a branch rather than shipped as a finished release.

The documentation site is linked for the develop branch, which is another indication that the published docs track the development line rather than the last release.

Editorial conclusion

Fluid fits a QtQuick team that has already chosen the Liri stack, or that wants Material Design components without designing a control set from scratch, since the build, the per-project embedding examples and the QML module layout are all in place. It is the wrong choice if you need an actively developed component library right now, because the last tagged release is 1.3.0 from 2023-11-10 and the last push was on 2026-10-14 on the develop branch, and it is the wrong choice on an old Qt, since it requires Qt 6.12 or newer with specific modules. Before you adopt it, read the CONTRIBUTING.md and the docs in the repository, and decide whether you will track the develop branch or pin the 1.3.0 release, because the README is explicit that develop may break from time to time.

Frequently asked questions

Official sources

1. Issues
2. lirios/fluid on GitHub
3. Project website
4. README
5. Releases