# FLTK: a C++ GUI toolkit that still expects you to compile it yourself > FLTK keeps its footprint small by asking almost nothing of the platform, but the repository is a C++ project where the 1.5 line in the README and the 1.4.5 release are two different things. **fltk/fltk** — FLTK - Fast Light Tool Kit - https://github.com/fltk/fltk - cross platform GUI development - Repository: https://github.com/fltk/fltk - Website: https://www.fltk.org - Stars: 2,324 · Forks: 341 - Language: C++ - License: NOASSERTION - Published: 2026-10-06 · Updated: 2026-10-06 · Language: en - Canonical page: https://hysenlabs.com/projects/fltk-fltk ## A toolkit named for staying small FLTK expands to Fast Light Tool Kit, and the README is direct about the intent: modern GUI functionality without bloat. It is a cross-platform C++ toolkit for UNIX and Linux on X11 or Wayland, Microsoft Windows, and macOS, with 3D graphics through OpenGL and a built-in GLUT emulation so GLUT code can be ported without hunting down glut libraries. The origin story is worth one sentence because it explains the design: originally developed by Bill Spitzak, now maintained by a small group of developers across the world with a central repository on GitHub. Copyright runs 1998 to 2025 and credits live in CREDITS.txt. A toolkit that has been reworked by a handful of people for nearly three decades tends to accumulate a lot of local convention, and the README reflects that in the way it talks. One structural detail explains a lot about the tree. There is no single src directory doing everything. The `FL/` directory holds the core widget library, `GL/` the OpenGL classes, `fluid/` the graphical UI designer, `test/` the test programs, and `documentation/` the manual sources. Bundled third-party code sits in clearly named folders: jpeg, png, zlib, nanosvg for SVG rendering, and libdecor for window decorations on Linux desktops. Vendoring dependencies like that is how the toolkit avoids pulling in a package manager's worth of transitive libraries. ## The licence allows commercial static linking FLTK comes with complete free source code under the GNU Library General Public License with exceptions, and the README names the exception as covering static linking. It also states plainly that FLTK can be used in commercial software, with a parenthetical that has been in the README for years: even Bill Gates could use it. That parenthetical is doing more work than it looks. The concern with an LGPL library is usually the obligation to let users relink a modified version. The static linking exception removes exactly that obligation for applications that link FLTK statically, which is the common case for a desktop tool that wants to ship as a single file. For an embedded instrument control panel or a Linux scientific application, that is a materially different licence from vanilla LGPL. The full text lives in the COPYING file at the repository root, with an online copy at fltk.org/COPYING.php, and the README notes that if COPYING is missing or damaged you should consult that page. If your compliance process needs the actual licence rather than the summary, that file is the source. The project also maintains a list of registered trademarks in the README, covering Microsoft, Windows, UNIX, OpenGL, and macOS. Unremarkable in itself, but it is the one part of the README written by someone anticipating a legal question. ## Building takes CMake and a C++11 compiler The prerequisites for 1.5 and later are CMake, a C++11 capable compiler such as gcc, clang, Visual Studio, or Xcode, and the system specific headers and SDK for your platform. On Unix and Linux those headers typically come from the package manager. The build itself is two commands: ```bash cd /path/to/fltk cmake . -B build cmake --build build ``` That creates a build folder inside the source tree, builds the library, and builds the test programs. CMake is used to generate the environment for whichever build tool you prefer, so make or ninja work after the initial configure if you used those generators. Installation is deliberately separated and deliberately discouraged by default: ```bash sudo cmake --install build ``` The README warns that this installs FLTK into a system directory for system wide use, and says plainly that it does not recommend doing so unless you know what you are doing. The alternative is to leave the library in your build tree and point your project at it, which is how most developers treat it. Documentation is generated from the source with Doxygen, and LaTeX is additionally needed for the PDF form. Two CMake targets handle it: ```bash cmake --build . --target html cmake --build . --target pdf ``` The README also admits a gap here, noting that more about building Fluid documentation is yet to be added. ## Master is on 1.5, but the newest release is 1.4.5 This is the first thing to sort out when you read the repository, because the README title says Version 1.5.0 while the newest published release is 1.4.5 from 2026-04-25. Those are not contradictory. Master is the development line for 1.5, and 1.4 is the stable series you would actually install. The two previous releases make the cadence visible: 1.4.4 on 2025-07-20 and 1.4.3 on 2025-04-29. Each is described as a maintenance release with bug fixes, and each states that its ABI and API are 100 percent backwards compatible with 1.4.0 and all previous 1.4.x releases. The recommendation in every release note is the same, namely that anyone on 1.3.x or an earlier 1.4 should upgrade. The compatibility story has a sharp edge that the release notes spell out repeatedly. FLTK 1.4 is intended to be mostly API compatible with 1.3.x, so you do not need to change source code, but the ABI has changed, which means every program must be recompiled. That is fine for a static toolkit with few dependencies. It is not fine if you have shipped a binary and cannot rebuild the thing that loads it. Since 1.4.1 the releases are hosted exclusively on GitHub, with links collected on the FLTK download page. The 1.4 series grew out of the final 1.3.4 release, and later fixes were backported to 1.3.5 through 1.3.11 and to a branch-1.3 branch. Chapter Migrating Code from FLTK 1.3 to 1.4 of the user documentation covers the source conflicts the notes refer to. The repository root backs all of this up with CHANGES_1.0.txt through CHANGES_1.4.txt alongside the current CHANGES.txt. ## Platform notes are scattered across a dozen README files The repository has an unusual documentation habit, and for a project of this age it is a good one. Instead of one long file, the root holds README.Unix.txt, README.Windows.txt, README.macOS.md, README.Wayland.txt, README.IDE.txt, README.CMake.txt, README.CPack.txt, README.Cairo.txt, README.abi-version.txt, README.documentation.txt, README.experimental.txt, and a plain README.txt. Each of those is a whole topic. README.CMake.txt is where CMake configuration gets depth. README.abi-version.txt exists to track the binary interface, which is the concern the release notes keep returning to. README.experimental.txt is how the project handles features that exist but carry a warning. README.Wayland.txt covers the newer Linux backend, and the presence of libdecor in the tree connects to it, since that is what supplies server side decorations when a window manager does not. Two other files tell you about the code's history and conventions. CREDITS.txt holds the copyright attribution the README points to, and .clang-format plus .clang-tidy at the root mean formatting and static analysis are enforced by configuration rather than by argument. The examples directory is conventional for FLTK: numbered test programs such as hello.cxx style utilities, howto-prefixed recipes for specific problems like drag and drop, adding file descriptors, parsing arguments, and remapping numpad keys, plus fluid-callback.fl showing how the designer integrates with code. The howto-prefix is the convention to follow if you contribute one. ## No binaries, and support moved from mailing lists to Discussions The README is unambiguous about distribution: FLTK does not provide pre-compiled binary distributions, and you should consult the package manager of your operating system. For a project whose whole proposition is a small native toolkit, that is the correct policy, and it means the build instructions above are not optional reading. Support has shifted over time and the README documents the current arrangement. The fltk.general mailing list on Google Groups remains the place for general questions, and registration instructions are at fltk.org/newsgroups.php, noted as possible without a Google account. Since July 2024 the project also offers GitHub Discussions, with a Q&A section for general questions about building and using FLTK. The distinction the README draws is about how to report what you find. If you are new to FLTK, unsure whether you have a bug, or just have a usage question, you are asked to post on fltk.general or in the GitHub Discussions Q&A category rather than filing an issue. Confirmed bugs go through the process on fltk.org/bugs.php. Given that the repository shows 63 open issues, a low number for a project with a few thousand contributors over nearly thirty years, that triage discipline appears to work. There is also a build badge in the README for the main build workflow and a second badge for building the Fluid user manual, which confirms the CI configuration compiles both the library and its designer's documentation. ## Conclusion FLTK is the right answer when your C++ program needs a window and you would rather not inherit a widget toolkit's opinions. The LGPL with exceptions for static linking lets you ship a commercial binary, the build is two CMake commands, and the widget set is the documented, conventional one rather than an extensible framework. The costs are equally plain: you install it yourself, you recompile when the ABI moves between series, and master is already on 1.5 while the newest published release is 1.4.5, which means the tree you clone is ahead of what most distributors package. Start from README.Unix.txt or README.Windows.txt for your platform, pin a 1.4.x tag if you need the stable series, and read CHANGES.txt before moving off a maintenance release. ## FAQ ### Is FLTK a good library? FLTK suits C++ programs that need a functional desktop window without a large dependency tree, and it is backed by an LGPL licence with a static linking exception that the README says permits commercial use. The trade is that you compile and install it yourself, and you recompile your applications when moving between the 1.3 and 1.4 series because the ABI changed. ### Which FLTK version should I use, 1.4.5 or 1.5? The newest published release is 1.4.5 from 2026-04-25, and that is the stable series to install. The README is titled for version 1.5.0 because the master branch is already the 1.5 development line. If you need the stable series, check out a 1.4.x release tag rather than building from master. ### Does FLTK support Wayland on Linux? Yes. The README names UNIX and Linux on either X11 or Wayland as supported targets, and the repository root carries a dedicated README.Wayland.txt with the specifics. The libdecor directory in the tree handles server side window decorations for cases where the desktop does not provide them. ### Does FLTK still work with OpenGL and GLUT programs? FLTK supports 3D graphics through OpenGL and ships a built-in GLUT emulation, so existing GLUT code can run without the separate glut library. The examples directory includes OpenGL test programs such as OpenGL3test.cxx and OpenGL3-glut-test.cxx, which show both routes side by side. ## Sources - [fltk/fltk on GitHub](https://github.com/fltk/fltk) - [Issues](https://github.com/fltk/fltk/issues) - [Project website](https://www.fltk.org) - [README](https://github.com/fltk/fltk/blob/master/README.md) - [Releases](https://github.com/fltk/fltk/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fltk-fltk