Re: GtkPreview changed behaviour

[Sven Neumann <sven gimp org>]

Hi,

maurits rijk philips com writes:

> >are you sure? I had a quick look at the state of the plug-in in CVS
> >and it seems as if preview_move() gets called since the coordinates
> >in the statusbar are correctly updated. 
> 
> Yep, that's one of the things I don't understand: the preview_move() get's 
> called, but the button_motion() isn't, even though both are connected to 
> the same event ("motion_notify_event").  Which makes me think right now 
> that I might have used the wrong declaration for preview_move(). If it's 
> supposed to return a value (will look that up this evening) I can imagine 
> that the other callback function is never called.

sure, all event callbacks have a gboolean return value (they used to
have in 1.2 too) and the signal emission is stopped after the first
signal handler returns TRUE indicating that it has handled the
event. I was assuming you read

 http://developer.gnome.org/doc/API/2.0/gtk/gtk-changes-2-0.html

Especially the part that says

"In GTK+ 1.2, if an event handler returned TRUE it prevented
 propagation of that event to parent widgets. That is, the event signal
 would not be emitted on parent widgets. In GTK+ 2.0, if an event
 handler returns TRUE, the current signal emission on the current
 widget is immediately stopped. That is, other callbacks connected to
 the signal will not be invoked."
 
> >The use of GDK_MOTION_NOTIFY as an event_mask (see your PREVIEW_MASK
> >definition) is wrong by the way. It didn't do any harm however.
> 
> Ah, ok I just copied that part from another plugin a long time ago. Why 
> shouldn't it be used and can I just remove it?

it is not part of the GDK_EVENT_MASK enum, you should just remove it.


Salut, Sven