Re: gtkmm compilation issue via jhbuild

["D. B." <db0451 gmail com>]

On Sun, Jan 1, 2017 at 12:00 PM, <gtkmm-list-request gnome org> wrote:

Date: Sat, 31 Dec 2016 22:59:15 -0600
From: Pavlo Solntsev <p_solntsev meta ua>
To: gtkmm-list gnome org
Subject: Re: gtkmm compilation issue via jhbuild
Message-ID: <1483246755.3065.8.camel@meta.ua>
Content-Type: text/plain; charset="UTF-8"

Thank you, D.B.

Could someone, please, explain briefly the overall model for
glib/gtkmm/libgdamm feature implementation? I mean, if I want to
introduce some features, I can provide a patch. It is clear. But where
should I implement my changes: gtk+gtkmm or there is a mechanism to add
features directly to gtkmm avoiding gtk. It will help me better
understand methodology of the aforementioned libraries.

Thanks.

Like those in many other languages, the mm libraries are bindings around GLib, GTK+, and other C libraries. They make the libraries usable from other languages.

In almost all cases, features should be added to the underlying C libs. In most cases they can be automatically added to the bindings. A combination of many clever tools written by binding authors and GObject introspection mean that often, newly added functions/properties/signals can be synchronised to the bindings automatically, with the only human intervention being to run a script that does so.

Occasionally, a binding will add a small convenience feature, or wrapping a C function/property/signal requires hand-written code, or etc. But usually, if you want a new feature, you really want it in the wrapped libraries, not the wrappers... as, I'm sure, do people who use the C libraries or prefer to use other languages' bindings.