after connected signals becomming useless?
- From: Tim Janik <timj gtk org>
- To: Owen Taylor <otaylor gtk org>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: after connected signals becomming useless?
- Date: Wed, 27 Jun 2001 16:53:40 +0200 (CEST)
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?
] [Thread Prev