Re: [gtk-list] Re: GtkEditable::activate bug or feature?

[Owen Taylor <otaylor redhat com>]

Havoc Pennington <hp@redhat.com> writes:

> Owen Taylor <otaylor@redhat.com> writes: 
> > 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.
> > 
> 
> The simplest solution to me is to add a convenience function
> like gnome_dialog_editable_enters(). Then you keep everything
> consistent. A gnome_dialog_editable_enters() type of function is
> certainly less inconvenient than breaking all existing
> activate-related code.

gnome_dialog_editable_enters() is not an attractive solution, because
the default is wrong. To get correct behavior, you have to call it on
pretty much _every_ entry in your program.

If people programming was the only thing to consider, then we could
simply do:

 if (gtk_signal_handler_pending (entry, signals[ACTIVATE], FALSE) || 
     entry->klass->activate)
   {
     gtk_signal_emit (entry, signals[ACTIVATE]);
     return TRUE;
   }
 else
   return FALSE;

And while it is theoretically ugly, it does not break any functioning
programs, and makes the default behavior right.

Unfortunately, this isn't going to work for gtk-- and probably not
for some other language bindings as well which _always_ are going
to fill something into entry->klass_activate. We do, however, need
to solve some other problems with the default handler slot and 
language bindings, so perhaps we can come up with a way of making
this work for all languages.

Regards,
                                        Owen