Re: GtkButtons and RUN_FIRST/RUN_LAST

[Tim Janik <timj gtk org>]

On Fri, 26 Oct 2001, Joel Becker wrote:

> On Sat, Oct 27, 2001 at 12:21:27AM +0200, Tim Janik wrote:
> > so ideally, ::clicked would be RUN_LAST, and GtkToggleButton.clicked()
> > would do nothing else than { set_state (!toggle_button->state); },
> > same for radio button, so it can be used as a differently drawn
> > toggle button.
> 
> 	I'm still not getting why the default of "user code is run
> before the state is correct" is considered ideal.   The only thing I can
> come up with is "in case the user wants to stop the signal".
> 	If the user wants to connect before the state is updated and
> happy, I would think it should be *explict*, so that a user likely knows
> what they are doing when they choose to do so.  Is the motivation for
> RUN_LAST merely to avoid having connect_before()?

pretty much yes.

we don't have an emission model of:
a) run user-before handlers
b) run default handler
c) run normal user handlers

because on occasions we really need to do stuff before any
user handler is being run. so we ended up with:

1) RUN_FIRST default handler (accumulate return value)
2) run normal user handlers (accumulate return values)
3) RUN_LAST default handler (accumulate return value)
4) run user-after handlers (accumulate return values)
5) RUN_CLEANUP default handler (return value is ignored,
   can't be intercepted)
(stages (1)-(4) are interceptable with emit_stop)

this model is, as a superset, at least functionally equivalent to the
above a)b)c) thingy, just the connect functions are named a bit differently.

> 
> Joel
> 

---
ciaoTJ