[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: [gtk-list] Re: GtkEditable::activate bug or feature?
From:       Owen Taylor <otaylor () redhat ! com>
Date:       2000-02-18 4:01:51
[Download RAW message or body]


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


-- 
         To unsubscribe: mail gtk-devel-list-request@redhat.com with 
                       "unsubscribe" as the Subject.

[prev in list] [next in list] [prev in thread] [next in thread]