Re: GtkButtons and RUN_FIRST/RUN_LAST

[Joel Becker <jlbec evilplan org>]

On Wed, Oct 24, 2001 at 02:07:58PM -0700, Manish Singh wrote:
> So while the RUN_LAST change now allows you to stop_emission on toggle
> buttons, it totally breaks the expected behavior for radio button clicked
> emissions. Requiring the use to use signal_after is lame and inconsistent
> with expected gtk behavior.

	Yosh and I were discussing this.  It seems there are only a few
useful states:

Explicit states:
o You want to run your user handler first to block the default.
o You want to run your user handler last to respond to what the default
  did.

Default states:
o You want normal user handlers to happen after the default, because the
  default updates state that the user handler will care about.
o You want normal user handlers to happen before the default because....
  because why?

	I couldn't come up with a situation or reason where a user
handler should run before the default handler unless explicitly
requested.  In most cases, the "naive" user handler will expect all of
the state changes the default handler causes to be in place.  In the
specific GtkRadioButton case, the user handler is called with
button->active at the wrong value.
	Based on this, it seems to me that the obvious default is for
the default handlers to run first, but to allow an explicit connect
*before* them to handle the emit_stop() case.  However, the current API
doesn't allow this.
	You *could* spec a g_signal_connect_before() function, or you
could replace g_signal_connect_data(..., after) with
g_signal_connect_data(..., when) and add G_CONNECT_DEFAULT = 0 and
G_CONNECT_BEFORE to GConnectFlags.  In this fashion, default connections
to button::clicked would run after the class handler, AFTER connections
would run even later than that, and BEFORE connections could be
explicitly allowed to run first.  These explicit BEFORE connections
could not rely on the state of the widget (which may be in flux due to
later class handlers), but can do things like emit_stop().  This would
solve the ToggleButton problem.
	However, it is likely too late to do this for 2.0.  We are left
with two solutions that I can think of:

o Keep old behavior.  You can't stop a ToggleButton from running its
  default handler.
o Keep new behavior.  Any button callback that the user adds that
  depends on the button's new state will break silently and confusingly.
  This seems to me to be the Wrong Thing, or as they say,
  <federico>BROKEN</federico>.

Joel

-- 

"Always give your best, never get discouraged, never be petty; always
 remember, others may hate you.  Those who hate you don't win unless
 you hate them.  And then you destroy yourself."
	- Richard M. Nixon

			http://www.jlbec.org/
			jlbec evilplan org