# GTK: the C toolkit behind the Linux desktop, built with Meson

> This GitHub repository is a read-only mirror of the GNOME GitLab project where GTK actually develops, which matters for where you file issues and which branch you build from. The build is Meson plus Ninja, and the licence is LGPL 2.1 or later with two Apache-licensed exceptions.

**GNOME/gtk** — Read-only mirror of https://gitlab.gnome.org/GNOME/gtk

- Repository: https://github.com/GNOME/gtk
- Website: https://gitlab.gnome.org/GNOME/gtk
- Stars: 1,705 · Forks: 423
- Language: C
- License: NOASSERTION
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/gnome-gtk

## This GitHub repository is a mirror, not the source of truth

The repository description says it plainly: this is a read-only mirror of the project hosted at gitlab.gnome.org/GNOME/gtk.

That single fact changes where several README instructions land. The build status badge points at gitlab.gnome.org. The bug reporting section says bugs should be reported on the issues page at gitlab.gnome.org/GNOME/gtk/issues, not here. The build-from-git section says the sources are hosted on gitlab.gnome.org.

So if you clone from GitHub you get the code, but your pull request, your issue and your CI status all live on the GitLab side. The main development branch is called `main`, and stable branches are named after their minor version, for example `gtk-4-10`.

There is a practical reason this mirror exists: GitHub is where many people look first, and a read-only copy is searchable and clonable without pretending to be the place work happens. Treating it as the place work happens is the mistake.

The canonical locations for everything else are listed near the top: the official download location at download.gnome.org/sources/gtk/, the web site at gtk.org, the developers blog at blog.gtk.org, and the discussion forum on GNOME Discourse under the platform core category.

## meson setup, meson compile, meson test

The build system is Meson with Ninja, and the three commands are the whole loop.

```sh
$ meson setup _build
$ meson compile -C_build
```

The test suite runs through the same tool rather than a separate harness.

```sh
$ meson test -C_build
```

And installation is a Meson subcommand, which means the install rules come from the build definition rather than a hand-written Makefile.

```sh
$ sudo meson install -C_build
```

The root confirms the layout: meson.build and meson.options at the top, with subprojects/ for bundled dependencies, build-aux/, po/ for translations, docs/, demos/, examples/, tests/ and testsuite/.

The source tree is split into the four layers the API docs mirror. gtk/ is the widget layer, gdk/ is the drawing and input abstraction, and gsk/ is the scene graph renderer that GTK4 uses for its own drawing. The nightly documentation is published separately for each, at gnome.pages.gitlab.gnome.org for gtk4, gdk4 and gsk4, which tells you the three are versioned and documented as distinct surfaces.

Full build documentation lives in the repository at docs/reference/gtk/html/gtk-building.html and online at docs.gtk.org/gtk4/building.html.

## The X11 dependency list is eight extensions long

The build requirements split cleanly by backend, and the X11 side is the one that surprises people because the list is long.

The common requirements are a C11 compatible compiler, Python 3, Meson and Ninja, plus GLib, GdkPixbuf, GObject-Introspection, Cairo, Pango, Epoxy, Graphene and Xkb-common.

The Wayland backend adds Wayland-client, Wayland-protocols, Wayland-cursor and Wayland-EGL.

The X11 backend adds Xlib and eight specific extensions.

```
xrandr
xrender
xi
xext
xfixes
xcursor
xdamage
xcomposite
```

If you are packaging GTK4 for a minimal system, this is the list that determines whether X11 works at all. A distribution that ships only a subset will compile and then fail at runtime in ways that look like application bugs.

The bug reporting checklist asks for the windowing system, X11 or Wayland, and for the graphics driver or mesa version, which is a hint about how much of a report depends on which backend you are running.

## LGPL 2.1 or later, with two named exceptions

GTK is released under the GNU Lesser General Public License, version 2.1 or, at your option, any later version. The COPYING file has the details.

The practical point the README makes is about commercial use: the LGPL terms allow GTK to be used by all developers, including those developing proprietary software, without any licence fees or royalties. That is the reason a toolkit of this size can sit inside closed-source applications, and it is a deliberate design choice rather than a workaround.

Two exceptions are called out, and they are the kind of detail a licence audit will find. GTK includes a small number of source files under the Apache licence: a fork of the roaring bitmaps implementation in gtk/roaring, and an adaptation of timsort from Python in gtk/timsort.

So a full inventory of what you are shipping is LGPL 2.1-or-later plus two Apache-licensed components. If your compliance process requires per-file attribution, those two directories are the files to look at, and the rest of the tree is covered by COPYING.

GitHub classifies this repository's licence as one it cannot map to a standard identifier, which is a metadata gap rather than an ambiguity: the README and COPYING both state the terms unambiguously, so read the file rather than the API field.

## Nightly flatpaks for the demos, and what that buys you

There is a fast way to see GTK4 in action without building anything, and the README documents it as three flatpak installs from the GNOME Nightly repository.

```sh
flatpak remote-add --if-not-exists gnome-nightly https://nightly.gnome.org/gnome-nightly.flatpakrepo
flatpak install gnome-nightly org.gtk.Demo4
flatpak install gnome-nightly org.gtk.WidgetFactory4
flatpak install gnome-nightly org.gtk.IconBrowser4
```

 The trade-off is that a nightly can break between two runs, so treat WidgetFactory4 output as indicative of the current widget set rather than as the set your distribution ships.

For day-to-day work, the stable branches named after their minor version are what you want, and matching your distribution's GTK4 minor version is what keeps your application building against the same headers and behaviour that ship on your users' machines.

## A bug report here has a shape, and the demos make it easy

The bug reporting section is unusually prescriptive, and it tells you how the project thinks about triage.

Include information about your system: the GTK version, the operating system and version, the windowing system, X11 or Wayland, the graphics driver or mesa version, the Linux distribution, and, if you built GTK, the list of options used to configure the build. Most of that is available in the GTK inspector, which is why the section points there rather than asking you to work it out.

Then include how to reproduce it, and the guidance is specific about the easiest case: if you can reproduce it with a demo application from demos/ or a test program from tests/, that is most convenient. Otherwise include a short test program exhibiting the behaviour, and as a last resort a pointer to a larger piece of software that can be downloaded.

If the crash printed something, the exact text is what they want, and stack traces are useful but not necessary.

That hierarchy, demo first, minimal program second, your application last, is the practical guidance for anyone triaging a GTK issue: the closer your reproduction is to the demos/ directory, the faster it moves.

## Conclusion

Adopt GTK if you are writing a native Linux desktop application in C and want a complete widget set without licence fees or royalties, since the LGPL terms are what let it sit inside proprietary software on those terms. Do not file issues against this GitHub copy, because it is a read-only mirror and the real issue tracker is on gitlab.gnome.org. Before you build, decide which backend you need, since the X11 path wants xrandr, xrender, xi, xext, xfixes, xcursor, xdamage and xcomposite while the Wayland path wants Wayland-client, Wayland-protocols, Wayland-cursor and Wayland-EGL, and then configure with meson setup _build.

## FAQ

### Is the GNOME/gtk GitHub repository the place to contribute?

No. It is a read-only mirror of gitlab.gnome.org/GNOME/gtk. The build status badge, the issue tracker and the build-from-git section all point to GitLab as the place where work happens.

### How do I build GTK from source?

With Meson and Ninja: `meson setup _build`, then `meson compile -C_build`. Run the tests with `meson test -C_build` and install with `sudo meson install -C_build`.

### What does building the X11 backend require?

Xlib plus eight extensions: xrandr, xrender, xi, xext, xfixes, xcursor, xdamage and xcomposite. The Wayland backend instead needs Wayland-client, Wayland-protocols, Wayland-cursor and Wayland-EGL.

### Can GTK be used in proprietary software?

Yes. The README states the GNU LGPL terms allow use by all developers, including those developing proprietary software, without any licence fees or royalties. GTK is LGPL 2.1 or, at your option, any later version.

### How can I try the GTK4 demos without building GTK?

Install the nightly flatpaks from the GNOME Nightly repository with `flatpak install gnome-nightly org.gtk.Demo4`, and similarly for org.gtk.WidgetFactory4 and org.gtk.IconBrowser4, after adding the remote with flatpak remote-add.

## Sources

- [GNOME/gtk on GitHub](https://github.com/GNOME/gtk)
- [Issues](https://github.com/GNOME/gtk/issues)
- [Project website](https://gitlab.gnome.org/GNOME/gtk)
- [README](https://github.com/GNOME/gtk/blob/main/README.md)

---

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