Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Introduction

peel is the project providing modern C++ bindings1 for GObject-based libraries, including GTK and GStreamer.

peel is designed to:

  • Integrate deeply with the GObject type system, supporting and faithfully exposing GObject features such as per-type instance and class initializers, properties, dynamic instantiation, and non-Object-derived types.

    This notably enables modern GTK patterns such as composite templates, list models, and expressions.

  • Have no runtime overhead compared to the equivalent code in plain C. peel follows the zero-overhead principle, which states:

    What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better.

    peel’s C++ wrappers are completely optimized away by the compiler, and the produced machine code is equivalent2 to what you’d get if you implemented the same logic in plain C.

  • Be easy to set up and use on a wide range of systems, including Windows. peel only requires C++11 (though there is some support for C++20 coroutines). peel’s bindings generator is written in Python with no external dependencies. There is some integration with CMake and Meson build systems, and peel can be easily pulled into your project as a Meson subproject.

  • Have very complete and up-to-date API coverage.

    The majority of the wrapper code is generated automatically based on GObject introspection data (GIR), and peel has rather good support for various GIR features, including some less used ones. This means that it’s easy to get peel working with pretty much any GObject-based library3, and that new features (like new libadwaita widgets) can be used with peel immediately when they appear in the upstream library—without having to wait for updated bindings to be uploaded to some sort of a central binding repository.

  1. “modern” here relates to “GObject bindings”, not “C++” ↩

  2. or at times better, when we’re able to take advantage of C++ features such as the strong type system to do things more efficiently than plain C ↩

  3. if a part of your project is implemented as an internal library, you should be able to use that with peel, too ↩