(In reply to comment #0)
> Hi,
> 
> Victor Porton reported in Debian bug http://bugs.debian.org/222615:
> """
> I am making essencially a GLib object which will save values of its
> properties to a file.
> 
> To not write file (a time consuming operaqtion) several times when several
> properties change in a row, it is reasobanle to write only at the time when
> all g_object_freeze_notify() are undone by g_object_thaw_notify().
> 
> So we need a signal which woul be emitted on last g_object_thaw_notify().
> Sadly in currentGlib there are no such signal.
> 
> Currently I'm going to work around this by using idle time handlers (or by
> using my_object_{freeze,thaw}_notify(). But it is a hack. Please add this
> signal.
> """
> 
> Do you think grouping of signals should be handled in special glib API?

thanks for forwarding the report. however, his approach of using an idle handler sounds perfectly suited to me, i'd actually have recommended it if he wouldn't use it already. the advantage of using an idler is that it can properly cope with common object state modification patterns such as (pseudo call stack):

+- main_loop
   +- idle_handler, saves object state
   +- event_dispatcher, modifies object state
      +- handler1
         +- freeze_notify
         +- modify property1
         +- modify property2 
         +- thaw_notify (emits notifies for property1, property2)
      +- handler1
         +- freeze_notify
         +- modify property3
         +- modify property4 
         +- thaw_notify (emits notifies for property3, property4)
   +- idle_handler, saves object state

under high loads, it might make sense to coalesce even multiple idle handlers (e.g. by using timeout handlers instead).

in any case, libgobject is very unlikely to gain an additional signal for freeze_notify. mainly because we already have a virtual function that can be used by derived object implementations to catch batch notifies and that feature proves to be allmost never used. the reason probably is, because the exact point in time where notifies are emitted is fairly arbitrary, considering that multiple functions in the call stack may freely issue freeze/thaw barriers and thus cause variying kinds of batch collections.

> 
> Bye,
> 

Thanks for your very complete response; I've forwarded it to the submitter.