Re: Properties, PropertyProxies and signals in glibmm

[Виталий Кирсанов <krokoziabla gmail com>]

Thank you Chris.

I considered glib's objectness so natural so that I didn't even think of it as something special. Of course glib's very main goal is to provide an object model for C language. :-)

So, you say sigc++ is more flexible than GSignal. Well, I need to play with it a bit. I haven't yet compared the features of both. And, who knows, since glibmm designers once decided not to use GSignal mechanism for newly created objects maybe in the future the implementation of Glib::Property object will migrate from GObject to another, new library.

By the way, about Glib::Property and Glib::PropertyProxy. I have dug a bit in glibmm's source code and found out how both of them work. Glib::PropertyProxy works similarly to Glib::SignalProxy* objects - it's just a wrapper, an interface to GObject properties. And one cannot register a new property by simply creating of a Glib::PropertyProxy in one's subclass of Glib::Object. And Glib::Property objects are really those who register new properties in GObject framework. And I believe Glib::Property objects are only supposed to be used internally in an Glib::Object's subclass implementation, leaving Glib::PropertyProxy as an API for the subclass's users. And also it is not needed to keep either Glib::PropertyProxy or Glib::SignalProxyProperty inside the subclass. They can be used rather as temporary objects, for instance when one calls their connect() or set_value() methods.

С уважением,

Кирсанов Виталий
ICQ: 193259120

2013/6/29 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