Properties, PropertyProxies and signals in glibmm



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.


Vitaly Kirsanov
ICQ: 193259120


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]