Re: GtkButtons and RUN_FIRST/RUN_LAST
- From: Joel Becker <jlbec evilplan org>
- To: Tim Janik <timj gtk org>
- Cc: Joel Becker <jlbec evilplan org>, Owen Taylor <otaylor redhat com>, Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: GtkButtons and RUN_FIRST/RUN_LAST
- Date: Sat, 27 Oct 2001 00:23:14 +0100
On Sat, Oct 27, 2001 at 12:58:06AM +0200, Tim Janik wrote:
> 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.
It isn't a superset, though. In the a)b)c) model, the user
handler connected with default semantics can expect the widget to be
done with its state. The latter model expects that all user handlers
will know the inconsistent state and behave accordingly. This is an
unecessary burden (IMHO) on library user.
I understand the logic of "Hey, we really need this to run
first". So yes, under that logic I can see why a button signal isn't
necessarily a candidate. But I still think that application developers
have a right to expect things to be in order when their handlers run,
unless they explicitly ask for something different. I'd want to see:
1) RUN_FIRST default handler (things we *have* to do first)
2) connect_before() user handlers (they know what they asked for)
3) RUN_LAST default handler (better known as RUN_DEFAULT. Normal stuff)
4) run normal user handlers (user needs no assumptions here)
5) connect_after() user handlers (again, they know what they want here)
6) RUN_CLEANUP default handler
I really just dislike forcing the user to understand the
limitations, inconsistencies, and other artifacts of the fact that
things are half-done when their handler is run. But I can work with the
current system for what I have to do, and I know the signal system's
ordering, so I will be ok. :-)
Joel
--
Life's Little Instruction Book #464
"Don't miss the magic of the moment by focusing on what's
to come."
http://www.jlbec.org/
jlbec evilplan org
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]