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 _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
