Re: GtkEntry::activate and GtkWindow default activation severely broken

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> widgets have the concept of actiavation, that is ::clicked for a button
> or a menu_item and ::activate for an entry

Well, actually...

  widget_class->activate_signal = menu_item_signals[ACTIVATE];
  widget_class->activate_signal = button_signals[ACTIVATE];

(GtkButton, in response to ::activate now does animation of button
pressing.)

>. the actiavate signal is
> intended to be used to hook up client callbacks to a widget, not to
> invoke widget specific magic (in fact, a widget should never need to
> implement an activate handler, this is purely meant for user notification).

I think the problem is that we have 2 or 3 different concepts
of "activate" floating around:

 A) The action performed to the default widget when Return is pressed
    or the focus widget when Space is pressed. This is the
    primary usage of:

     widget_class->activate_signal = blah;

 B) A signal that tells the application when the widget is triggered
    in some fashion.

GtkButton is purely A), GtkMenuItem is purely B). GtkEntry
currently is somewhere in between.

> for GtkEntry, there shouldn't be a gtk_entry_real_activate()
> implementation at all.

Currently, we have:

  /* Activate */

  gtk_binding_entry_add_signal (binding_set, GDK_Return, 0,
				"activate", 0);

  gtk_binding_entry_add_signal (binding_set, GDK_KP_Enter, 0,
				"activate", 0);

So, if we needed to get rid of gtk_entry_real_activate(), we'd
have to separate out the action signal from the notification
signal.

> instead, whether Return/Enter on an entry
> should activate the entry, or call gtk_window_activate_default()
> instead, needs to be determined before the signal is being emitted.
> that is, entry->activates_default should indicate whether Return/
> Enter on an entry trigegrs entry activation or a window's default
> widget activation,

>  not what extra actions occour once ::activate
> is emitted on the entry which is a GTK_RUN_ACTION signal
> btw, so might be called from anywhere any time.

Well, either we need to split out the GTK_RUN_ACTION component
or the real_activate() function _definitely_ needs to exist :-)

I suppose we probably should split out the action signal from the
notification signal, on the theory that action signals should be
clearly distinct from notification signals, though we have
the same combination for GtkButton::clicked and 
GtkMenuItem::activate.

But splitting them apart doesn't actually do anything for your
loop by itself. I think the answer to that is simply to remove:

  widget_class->activate_signal = signals[ACTIVATE];

Since I don't think that actually does anything useful for us. 

As for how to deal with the multiple different uses of the
word activate, I don't a good solution that doesn't make
for lots of unnecessary API breakage. (And would involve
coming up with alternate names.) The main thing we might
want to do is rename GtkButton::activate to discourage
people from connecting to it.

Regards,
                                        Owen