Re: GTK_RUN_FIRST and return from default signal handler

[Owen Taylor <otaylor redhat com>]

George <jirka@5z.com> writes:

> gtk won't let me set up a signal where the default handler is GTK_RUN_FIRST
> and there is a return type ...
> 
> this means that the return type will only be taken from the default handler
> which is NOT what I want ... (if I connect the signal somewhere else the
> return value is ignored unless the default handler is NULL) ... this seems
> to be NOT right

The reason the combination of GTK_RUN_FIRST and a return value is
considered bad is that with the combination there is no way to
connect a signal handler and not change the return value.

Making such a signal GTK_RUN_LAST gives the application programmer
the option of either overriding the return value (connect_after())
or not overriding it (conect()).

>  ... I solve it by not having ANY return from the return 
> handler (making it a void function and casting it) ... this is ugly

Hmmm, that sounds like a recipe for getting a junk result.

> wouldn't jsut the opposite make sense ... allow only GTK_RUN_FIRST when there
> is a return type
> 
> plus the message says:
> 
> Gtk-WARNING **: gtk_signal_newv(): signal "pressed" with return value `gboolean' excludes GTK_RUN_LAST

[...]

> which sounds very confusing to me .. it seems like the code is actually
> excluding GTK_RUN_FIRST
Yes, that warning message is messed up. I've changed it to:

Gtk-WARNING **: gtk_signal_newv(): signal "pressed" - return value "gboolean" is incompatible with GTK_RUN_FIRST.

(I'm not really sure this should be a warning or error at all,
 but it's the most effective way of encouraging people to
 avoid GTK_RUN_FIRST. There are a large number of places in
 GTK+ where a signal that originally was RUN_FIRST was later
 changed to RUN_LAST because applications needed the ability
 to override it.)

Regards,
                                                  Owen