Re: Use of GObject properties in GTK+ 2.0

[Tim Janik <timj gtk org>]

On 21 Feb 2001, Havoc Pennington wrote:

> 
> "Padraig O'Briain" <Padraig Obriain ireland sun com> writes:
> > A quick perusal of the GTK+ 2.0 code suggests that GtkObject arguments are 
> > implemented as GObject properties.
> > 
> > In the GObject source code I came across the signals "properties_changed" and 
> > "notify".
> > 
> > I did not find any code in gobject.c which connected what looks like the
> > signal handlers, i.e. g_object_notify_property_changed()  and
> > g_object_property_changed(), to the "properties_changed" and "notify" signal.
> > Did I miss something?
> > 
> > Is the "properties_changed" signal in GObject a public interface which we
> > can use to connect a signal handler to be invoked when the property changes?
> > 
> > My interest in this is that the Accessibility API which we are trying to define 
> > needs to be able to add and remove what is Java termininology are property 
> > change listeners.
> > 
> > 
> 
> If you look at tests/testtreeview.c there's some code which uses the
> notification. 
> 
> I am totally mystified by why there are two signals,
> properties_changed and also notify - I think there should be only
> notify. But, maybe Tim can explain that.

with the freeze and thaw notify fucntions in gobject, a bunch of properties
can queue up that notification is required for. the actuall notification will
then be emitted at thaw time, causing multiple GObject::notify signals with
different details (the details being the property names).
if you implement a listener that does some expensive action in response to
property changes, you'd probably rather be notified with the whole list of
properties that have changed than on each individual property. in that case
you'd connect to ::properties_changed. the most frequent use though is
people connecting to GObject::notify::<detail>.

> 
> Havoc
> 

---
ciaoTJ