Re: GtkEditable::activate bug or feature?

[Owen Taylor <otaylor redhat com>]

Matt Goodall <mgg@isotek.co.uk> writes:

> Hi,
> 
> Does anyone else consider it a bug that a GtkEditable swallows the enter
> key event even if it has no handlers connected to its activate signal? I
> would have expected it to let the event fall through to its parent so
> that it could trigger a default button.
> 
> I'm currently downloading the GTK+ source to have a look but I presume
> other keys get "let through", i.e. tab and other focus change keys.
> 
> Also, is there an official place to report bugs to or have I just done
> it?

The official place to report bugs is the GNOME bug tracker. See the
README file in the GTK+ distribution for details of how to 
report bugs.

This particular issue has been discussed before. The reason for the
current behavior is that signals like "activate" are conceptually
notification. Merely connecting to a signal should not change behavior.

>From a standpoint of interface correctness, this is the right thing to
do.  However, it does occur to me that this is sacrificing useability
for the user for the sake of making things a bit easier understand
for the programmer.

Upon reflection we probably should just bite the bullet, make "activate"
behave in a way that is inconsistent with the other signal, and document
the exception.

The other alternative would be to add a return value to "activate" in
GTK+-1.4 that acted like the events; where returning TRUE indicates
that the event has been handled and no further action is necessary.

The trouble with this is that its an incompatible change that doesn't
get caught either in the compilation stage or with a runtime warning,
but simply gives you random behavior if you have old activate handlers
that don't return a value. Also, I'm not really sure that it would
ever be useful to catch "activate" and then let the return key press
go to cause the default widget to be activated. 

Regards,
                                        Owen