Re: About events propagation in gtk+-1.3.3

[Havoc Pennington <hp redhat com>]

Mario Motta <mmotta guest net> writes:
> Hi all GTK+ mantainers,

BTW, you should be sure that bugs go in bugzilla.gnome.org.

> i have noticed a strange behaviour about event propagation: in several
> widgets happens that if an event-callback returns TRUE it prevents
> further event dissemination also for others separated connections. 

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.

If this causes problems a bugzilla report for each specific issue
would be excellent. Normally problems will be caused by callbacks that
return the wrong value.

> However this behaviours ends with errors: for instance applying drag and
> drop
> capability to some widgets makes them insensitive to other event/signal
> such as "click" or others. This because into the event callback
> gtk_drag_source_event_cb () the retval is always TRUE. Setting a retval
> to FALSE restablishes right behaviour and you can both drag and/or click
> a
> button for instance. 

There's some fixing that needs to happen there. Not obvious to me what
the right fix is. I'm guessing the dnd handler should return FALSE,
since until the drag threshold is passed you don't know the event has
been handled.

Anyhow, would be good to get this in bugzilla.

>Other examples can be made: in GtkTextView for
> instance, making a
> connection to key_press_event and returning TRUE from the handler, this
> makes the overall widget insensitive to further key presses. 

That's correct behavior. If your handler does not handle the event,
only listens to it, then it should return FALSE. This way you can use
your key press handler as a filter, and keep the textview from
receiving events you are doing something else with.

> Also if you connect a window with configure_event and return TRUE from
> the handler, this makes all widgets to do not honour geometry requests
> (such as window resizing, maximimizing,etc). A work around is to
> connect_after or return FALSE but often this is not possible or
> convenient. 

In what case would it be impossible or inconvenient to type FALSE
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.)

Havoc