Re: Properties, PropertyProxies and signals in glibmm

[Chris Vine <chris cvine freeserve co uk>]

On Sat, 29 Jun 2013 13:36:46 +0400
Виталий Кирсанов <krokoziabla gmail com> wrote:
> Hello list.
>
> I'm going to design a custom subclass of Glib::Object and this makes
> me be pondering about the internals of glibmm, its relationship with
> glib. As far as I understand the main asset of gobject library
> consists in providing a framework for building objects which can 1)
> notify the world about events by means of signals and 2) keep
> properties which can be read/written in a standard manner. I will use
> both these features in my C++ program so I want to understand how I
> should create/register new properties and signals of my subclass.
>
> gobject library provides quite clear interface for registration of new
> signals and properties (I'm talking about g_signal_new() and
> g_object_class_install_property() functions). But it becomes a bit
> more difficult when the matter goes to glibmm wrappers.
>
> *The first thing I do not understand is what the difference betwen
> Glib::Property and Glib::PropertyProxy is. *Which of them should I
> use? If I declare a member of Glib::Property type in my subclass and
> initialise it in the subclass's constructor then AFAIU it leads to
> invocation of g_object_class_install_property() in the end and I have
> a true gobject property connected to my object. Why then is
> Glib::PropertyProxy needed? Just to give the reference to
> Glib::SignalProxyProperty object? And moreover another thing is vague
> to me. The docs for Glib::PropertyProxy says.* *
>
> *
> *
> *You may register new properties for your class (actually for the
> underlying GType) simply by adding a PropertyProxy instance as a class
> member. However, your constructor must call the Glib::ObjectBase
> constructor with a new GType name, in order to register a new GType.*
> *
> *
>
> Does it mean I need to declare Glib::PropertyProxy in my subclass to
> register a new property rather than Glib::Property? If yes, why then
> is Glib::Property needed at all?
>
> *Another thing about signals. *From the glibmm documentation I can
> conjecture that the designers of glibmm decided not to use gobject
> signalling mechanism for new subclasses of Glib::Object class; instead
> sigc++ library was supposed to be used for that (while for the
> existing glib objects (e.g. gtk widgets) signal proxies were invented
> so that to provide sigc++-like interface for their signals). Can
> anybody explain why such an inconsistent descision was taken? I mean
> if glibmm is in essence a set of wrappers for glib then why should it
> adopt any native C++ mechanisms? One gets a bit surprised when one
> learns that new properties and signals are created using different
> techniques in glibmm while there is one common tecknique in glib.

The principal purpose of GObject is to provide an object system, with
inheritance, interfaces, virtual methods and the like, for C.  C++
already has an object system.  The principal purpose of glibmm's own
interface for GObject is to enable you to extend GObjects when you
derive from the glibmm/gtkmm wrapper of a particular GObject type
provided by GTK+.  For other cases, C++ generally already does what you
need.

libsigc++ is much more flexible than GSignal.  signal proxies are needed
to map GSignals to libsigc++ signal objects for gtkmm.

I have never tried to add GObject properties to gtkmm's wrapper classes
so I can't help you with that one.  (I am not saying there is never a
use for it: you would need it if the new property is to be recognised by
GObject itself.  But I have never encountered a use which I did not
deal with by standard derivation, by adding data members or proxies to
the derived C++ class itself.)

I am sure there are interesting things that can be done with glibmm's
wrapping of GObject, and if you develop them it would be good to hear
more about it.

Chris