Re: [pygtk] connect_after does not work for treeview

[James Henstridge <james daa com au>]

Christian Reis wrote:

> On Fri, Mar 21, 2003 at 10:31:13AM +0800, James Henstridge wrote:
>  
>
> > Stephen Kennedy wrote:
> >
> >    
> >
> > > Plain "connect" works fine, but the "connect_after"
> > > callback does not get called.
> > > Or am I doing something wrong? See attached example.
> > >      
> > For the standard widget event signals, a custom accumulator is set.  
> > When going through the list of handlers to call for the signal, the 
> > process goes like this:
> >
> >   1. call handler
> >   2. if it returned True, skip the rest of the handlers in the list and
> >      return True
> >   3. otherwise, continue to the next handler
> >
> > GtkTreeView handles button press events, so its handler will return 
> > True.  If you have a handler further down the list, then it won't get 
> > called.
> >    
>
> How does connect/connect_after relate to the `position' of the callback
> in the list of handlers? Does connect() connect *before* the
> GtkTreeView's `default' signal handler (can I call it default?) and
> _after(), after? What about multiple connect()/_after()s? If this is
> true, then this exemplifies:
The callback order is:

  1. run the class handler if the G_SIGNAL_RUN_FIRST flag is set.
  2. run all handlers connected with g_signal_connect() in the order
     they were connected.
  3. run the class handler if the G_SIGNAL_RUN_LAST flag is set.
  4. run all handlers connected with g_signal_connect_after() in the
     order they were connected.
  5. run the class handler if the G_SIGNAL_RUN_CLEANUP flag is set

Most signals only have the RUN_FIRST or the RUN_LAST flag set, and 
signals with return types are usually just RUN_LAST (such a signal can't 
have only RUN_FIRST set).  Hence, all the "*_event" signals are RUN_LAST.

> My assumption is that if foo_event is emitted in the widget, these
> callbacks will be called in order, and that any return gtk.TRUE will
> stop the callback chain. Am I correct?
Yes.  That is what the accumulator for the event signals do (this isn't 
the default behaviour for signal emissions).

> One major confusion I note is when to use return TRUE and when to use
> stop_emit_by_name() inside the callback - when is one or the other to be
> used? Do we use stop_emit_by_name() to stop *other* emissions apart from
> the current (foo_event) one?
Most uses of stop_emit_by_name() can be converted to simply do "return 
True" now.  You hardly ever need to manually stop the emission for event 
signals in GTK 2.x.

James.

--
Email: james daa com au
WWW:   http://www.daa.com.au/~james/