Re: [pygtk] connect_after does not work for treeview

[Christian Reis <kiko async com br>]

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:

(D: default, C1: first connect()ed callback, A1: first _after()ed
callback, etc)

w = gtk.Foo()

    foo_event callbacks: D 

w.connect("foo_event" C1)

    foo_event callbacks: C1 D 

w.connect("foo_event", C2)
    
    foo_event callbacks: C1 C2 D 

w.connect_after("foo_event", A1)
    
    foo_event callbacks: C1 C2 D A1

w.connect_after("foo_event", A2)
    
    foo_event callbacks: C1 C2 D A1 A2

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?

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?

At the end of all this I'll produce a list of widgets that have default
handlers. For me, this is often a point of major confusion.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL