# TGUI separates its widgets from the three graphics backends it draws them with

> TGUI is a Zlib licensed C++ GUI library that started as an SFML extension and now runs on SFML, SDL, GLFW and raylib through eleven backend configurations, from SFML_GRAPHICS to RAYLIB. The widget layer is independent of the windowing, font and rendering libraries, and each backend declares its own minimum versions in a table.

**texus/TGUI** — Cross-platform modern C++ GUI

- Repository: https://github.com/texus/TGUI
- Website: https://tgui.eu
- Stars: 1,079 · Forks: 113
- Language: C++
- License: Zlib
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/texus-tgui

## The backend matrix is the design

TGUI is a cross-platform C++ widget library that originated with SFML and now supports SDL, GLFW and raylib backends. The project's current support matrix lists separate OpenGL, OpenGL ES, Vulkan, SDL renderer and raylib configurations, with platform support and uncertainty varying by row.

For example, GLFW_OPENGL3 is listed for Windows, Linux and macOS, while several GLES and raylib configurations include Emscripten. Some iOS and Vulkan entries carry uncertainty marks. Consult the matrix for the exact release and test your chosen platform/backend combination; backend support does not make every integration detail interchangeable.

## Each backend declares its own minimum versions

The dependency table is the second half of the support story, and it is a table of minimum versions per backend rather than a single list of dependencies.

| | Window backend | Font backend | Rendering backend |
|---|---|---|---|
| SFML_GRAPHICS | sfml-window (>= 2.5) | sfml-graphics (>= 2.5) | sfml-graphics (>= 2.5) |
| SFML_OPENGL3 | sfml-window (>= 2.5) | FreeType (>= 2.6) | OpenGL (>= 3.3) |
| SDL_GPU | SDL (>= 3.2) | SDL_ttf (>= 3.2) | SDL (>= 3.2) |
| SDL_RENDERER | SDL (>= 2.0.18) | SDL_ttf (>= 2.0.14) | SDL (>= 2.0.18) |
| SDL_TTF_OPENGL3 | SDL (>= 2.0.6) | SDL_ttf (>= 2.0.14) | OpenGL (>= 3.3) |
| SDL_TTF_GLES2 | SDL (>= 2.0.6) | SDL_ttf (>= 2.0.14) | OpenGL ES (>= 2.0) |
| SDL_OPENGL3 | SDL (>= 2.0.6) | FreeType (>= 2.6) | OpenGL (>= 3.3) |
| SDL_GLES2 | SDL (>= 2.0.6) | FreeType (>= 2.6) | OpenGL ES (>= 2.0) |
| GLFW_OPENGL3 | GLFW (>= 3.2) | FreeType (>= 2.6) | OpenGL (>= 3.3) |
| GLFW_GLES2 | GLFW (>= 3.2) | FreeType (>= 2.6) | OpenGL ES (>= 2.0) |
| RAYLIB | raylib (>= 4.2) | raylib (>= 4.2) | raylib (>= 4.2) |

The font backend column is the one to read carefully, because it shows the abstraction is not total. SFML_GRAPHICS draws its own text through sfml-graphics, raylib draws its own through raylib, and everything else needs either SDL_ttf or FreeType brought in separately. So a project that starts on SFML_GRAPHICS and later wants the OpenGL 3 backend takes on a font dependency it did not have before.

The two windowing libraries behave the same way. SDL_TTF_OPENGL3 needs both SDL and SDL_ttf, while GLFW_OPENGL3 needs GLFW and FreeType, and mixing them would be a choice with consequences for the build.

The RAYLIB row is the simplest, with a single dependency for all three roles at 4.2 or newer, which is what makes raylib the easiest backend to start with if you have no existing windowing library.

The matrix lists GLFW_OPENGL3 on macOS, while GLFW_GLES2 does not list macOS support. Check the selected backend's current support and dependency versions rather than assuming all GLFW configurations are equivalent.

## One example per backend, and the build is CMake

The repository layout shows how the project is organised, and the examples directory is the clearest evidence that the backends are genuinely separate rather than a facade over one implementation.

The example files are named after the configuration they exercise: main-SFML_GRAPHICS.cpp, main-SFML_OPENGL3.cpp, main-SDL_RENDERER.cpp, main-SDL_GPU.cpp, main-SDL_OPENGL3.cpp, main-SDL_GLES2.cpp, main-SDL_TTF_OPENGL3.cpp, main-SDL_TTF_GLES2.cpp, main-GLFW_OPENGL3.cpp, main-GLFW_GLES2.cpp and main-RAYLIB.cpp, and there are also directories for Android, Emscripten and iOS, plus many_different_widgets/ and scalable_login_screen/ as larger samples.

One example per backend is the right way to keep a multi-backend library honest. A single example would work on the backend the author develops against, and the others would rot. Ten examples means the widgets are known to work on all ten paths, or the CI says otherwise.

The build is CMake with a CMakeLists.txt at the root and a cmake/ directory, and the top level also has an Android.mk for the Android build and a .clang-format for the formatting, plus gui-builder/ which is a tool for assembling interfaces, themes/ for the theme files, include/ and src/ for the library, doc/ for documentation, tests/ for the test suite, and a changelog.md.

The tests are backed by CI in GitHub Actions with a codecov coverage badge on the 1.x branch, and the status section at the top of the README carries both badges.

The library itself is Zlib licensed, with a license.txt at the root, and the contact section names Bruno Van de Velde as the author, with a Discord invite, a GitHub sponsor link and a PayPal donation link, and the topics list the gamedev context alongside the cross-platform, sfml and ui tags.

## A nightly build tag alongside the versioned releases

The release history has an entry that is worth noting. The most recent tag is nightly_build, Nightly build, dated 2026-10-04, and the last push to master was on the same day, 2026-10-04. The versioned releases below it are v1.13.0 from 2026-06-24 and v1.12.1 from 2026-04-18.

So the project publishes a moving nightly in addition to its stable releases, and the nightly is what the recent activity is going into. The default branch is 1.x, which means the current major line is 1 and the nightly is presumably a build of that branch.

The Download section describes the two ways in. You can download the source code of the current development version from the git repository, with a direct link to the 1.x branch as a ZIP, and precompiled libraries for some compilers are available for each release.

The for some compilers qualifier is worth holding on to. A C++ library with a C++20-class feature set and no stable ABI has to be recompiled per compiler, so the precompiled binaries are a convenience for a specific toolchain rather than a drop-in, and a project on a different compiler will build from source. That is normal for a header and source C++ library of this kind, and it is worth checking before you plan around a binary download.

The documentation structure is a set of separate sites under tgui.eu, with a widgets overview, the tutorials, the documentation, the examples and a forum at forum.tgui.eu. The version in the paths is 1.0, so the online documentation is written against the 1.x line.

## Where TGUI is the wrong choice

The first wrong case is a project that wants a native interface. TGUI draws its widgets with the graphics backend, which means a button is a textured rectangle in a window your program owns, and it looks the same on every platform. A team that wants its desktop application to look like a desktop application on macOS, with the system title bar and the system controls, is looking for a different library, because a cross-platform toolkit that draws its own chrome has by definition given that up.

The second wrong case is a web project. The Emscripten column is the tell. The current matrix lists Emscripten support for SDL_RENDERER, SDL_TTF_GLES2, SDL_GLES2, GLFW_GLES2 and RAYLIB. Browser deployment still needs an Emscripten build and backend-specific testing; check the matrix for the revision you use.

The third wrong case is a team that wants to use an existing immediate-mode or retained-mode library. TGUI is a retained-mode widget library with its own widget set, and if your project has already committed to ImGui, Nuklear, wxWidgets or Qt, adding a second GUI library means two input systems, two font handling paths and two sets of assets.

The fourth wrong case is a project that needs to reach a platform the table marks as unsupported for the configuration you want. The iOS column is mostly empty, with only SFML_GRAPHICS, SDL_RENDERER and SDL_TTF_GLES2 having a checkmark, and Android excludes the OpenGL 3 configurations entirely. If your target is an iOS game with a custom OpenGL renderer, there is no configuration here that does it.

## How it differs from using the backend library directly

The comparison worth making is with drawing your interface with SFML or SDL directly, and the difference in approach is what you stop having to write.

The windowing and graphics libraries provide the primitives. A rectangle, a sprite, a texture, a font, a text string, an event queue with a key code and a mouse position. Everything above that, the button that knows it is hovered, the text field that has focus and shows a caret, the scroll area that clips its children, the dropdown that opens and closes on the right key, is yours to write, and each of those is a small piece of state machine and a small piece of hit testing and a small piece of event dispatch.

TGUI provides that layer. The widget set, the layout behaviour, the focus management, the event routing to the right widget, the theming, and the drawing of all of it, sit above the backend. The backend is reduced to what it should be, a surface to draw on and an event source to read from.

The second difference is the portability that the backend matrix buys. If your project is on SFML because of an existing renderer and you later need to run on a platform SFML does not cover, you change the backend configuration and the widget code stays as it is. With no widget layer, that migration means rewriting the interface.

The third difference is theming. The README shows a light theme and a black theme screenshot, and there is a themes/ directory in the repository, so the appearance is data rather than code, and a project can restyle the whole interface without touching the widget implementations.

The fourth difference is what TGUI does not do. It is a widget library, not a full application framework. There is no scene graph, no asset pipeline, no layout editor beyond the gui-builder/ directory, and no application lifecycle. A team that wants a game engine with a UI layer needs the engine as well, and the engine is not in this repository.

## Conclusion

TGUI fits a C++ developer who wants a retained-mode widget toolkit that runs on whichever windowing library the project already uses, particularly a game project on SFML or SDL, and it fits a team that wants to switch backends without rewriting the interface. It does not fit a web developer, and it does not fit a project that needs a native look on every platform, since the widgets are drawn by the graphics backend rather than by the system. Before adopting it, check the backend support table for your target platform, since SFML_GRAPHICS is the only configuration with a checkmark for every platform, and note that the current release is v1.13.0 from 2026-06-24 with the last push on 2026-10-04.

## FAQ

### Which graphics backends does TGUI support?

SFML, SDL, GLFW and raylib, in eleven named configurations including SFML_GRAPHICS, SFML_OPENGL3, SDL_GPU, SDL_RENDERER, SDL_TTF_OPENGL3, SDL_TTF_GLES2, SDL_OPENGL3, SDL_GLES2, GLFW_OPENGL3, GLFW_GLES2 and RAYLIB, with the platform support for each listed in a table in the README.

### Which TGUI backend should I choose for the widest platform support?

SFML_GRAPHICS, which is marked supported on Windows, Linux, macOS, Android and iOS. SDL_RENDERER is also broadly supported including on Emscripten, and it only needs SDL and SDL_ttf at version 2.0.18 and 2.0.14 or newer, while the OpenGL configurations are desktop only.

### What are TGUI's dependencies for a given backend?

They depend on the configuration, and the README gives a table with a window backend, a font backend and a rendering backend per row. SFML_GRAPHICS needs sfml-window and sfml-graphics at 2.5 or newer, GLFW_OPENGL3 needs GLFW 3.2 or newer with FreeType 2.6 or newer and OpenGL 3.3 or newer, and RAYLIB needs raylib 4.2 or newer for all three roles.

### Is there a prebuilt binary of TGUI I can use?

Precompiled libraries for some compilers are available for each release on the releases page, and the current development source can be downloaded as a ZIP from the 1.x branch. Because it is a C++ library without a stable ABI, the precompiled libraries are tied to a specific toolchain and other compilers will need to build from source.

### Who maintains TGUI and what licence is it under?

The project is by Bruno Van de Velde, and it is Zlib licensed with a license.txt at the root of the repository. The recent releases are v1.12.1 from 2026-04-18 and v1.13.0 from 2026-06-24, plus a nightly_build tag from 2026-10-04, and the default branch is 1.x.

## Sources

- [License: Zlib](https://github.com/texus/TGUI/blob/1.x/LICENSE)
- [Project website](https://tgui.eu)
- [README](https://github.com/texus/TGUI/blob/1.x/README.md)
- [Releases](https://github.com/texus/TGUI/releases)
- [texus/TGUI on GitHub](https://github.com/texus/TGUI)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/texus-tgui