Re: [pygtk] connect_after does not work for treeview

[Christian Reis <kiko async com br>]

On Tue, Mar 25, 2003 at 10:10:32PM +0800, James Henstridge wrote:
> > 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

Can the class handler be run multiple times, then, if both _LAST and
_FIRST are set, for instance?

> 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.

What are signals with return types?

> > 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).

How does it work for signal emissions, and how does it differ from event
signals? I should write up a FAQ on this, the tutorial doesn't make it
nearly clear enough.

> > 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.

Why did we have to do it back in GTK 1.2?

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