Re: About events propagation in gtk+-1.3.3

[Owen Taylor <otaylor redhat com>]

Paul Davis <pbd Op Net> writes:

> Havoc writes:
> 
> >That's correct; returning TRUE from an event callback now stops the
> >current signal emission. It should not however affect subsequent
> >emissions, it sounds like you are saying it does?
> >
> >Callbacks should return TRUE if they have handled the event, and FALSE
> >if they just listened to it, and someone else can still handle it.
> >In what case would it be impossible or inconvenient to type FALSE
> 
> and
> 
> >instead of TRUE? The return value simply means "run further handlers,
> >I didn't handle it" or "do not run further handlers, I consumed the
> >event." So you have to return the one you mean. (This was also true in
> >GTK 1.2, it's just that the consequences of getting it wrong weren't
> >very noticeable.)
> 
> Does all of this mean that returning TRUE will stop the default
> handler as well ? I have always found this a confusing aspect of the
> GTK+ signal system: returning TRUE stops other explicitly connected
> handlers, but it (often?) doesn't seem to stop the default handler ...

Actually, it never stopped any signal handlers in GTK+-1.2. It just
stopped _further_ propagation of the event. If you happened to be
the last signal handler connected. (since otherwise your return value
would be ignored.)

People tended to get confused about this and often omitted 
gtk_signal_emit_stop_by_name() when they should have included it.
(Resulting in multiple signal handlers handling a signal, stuck grabs,
etc.)

For GTK+-2.0, we are changing that so that a TRUE return stops emission
immediately. It's not fixed in stone that this behavior will be kept
in the final GTK+-2.0; it clearly does introduce some breakage and
inconveniences of its own. But we thnk it is, on the whole, a much
less confusing behavior.

Regards,
                                        Owen