after connected signals becomming useless?

[Tim Janik <timj gtk org>]

hey owen,

you remember our (very old) discussion about _after_ connected
handlers only being usefull for notification, since they're
effectively run after a widget's default handler?

however, with TRUE aborting ::*_event signals, and class handlers
finally (and correctly) returning TRUE when they handled something,
_after connections are never being executed.
i just ran across this for the clist:

  "swapped_signal_after::button_press_event", gtk_clue_hunter_clist_click, clue_hunter,

the thing is, the clist default handler definitely needs to be run before
gtk_clue_hunter_clist_click() to update selections etc, but
gtk_clue_hunter_clist_click() still needs to catch double-clicks.

yeah, for this special case, i could cook up some hackery with
intercepting ::event or deriving from clist, but that'd really
be the wrong approach.
we have a deeper problem here, that of _after handlers becoming useless
for _event functions. we can't even change the current semantics to
still execute a signal emission's after-stage after some handler
returned TRUE, because that'd still execute after handlers which
weren't executed in 1.2 due to emit_stop.

what are your thoughts on the issue?

---
ciaoTJ