On Sun, Jan 1, 2017 at 12:00 PM, <gtkmm-list-requ...@gnome.org> wrote:
> > Date: Sat, 31 Dec 2016 22:59:15 -0600 > From: Pavlo Solntsev <p_solnt...@meta.ua> > To: gtkmm-list@gnome.org > Subject: Re: gtkmm compilation issue via jhbuild > Message-ID: <1483246755.3065.8.ca...@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.
_______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
