Re: after connected signals becomming useless?

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> 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.

I don't actually see the problem here - connect non-after, and if
return FALSE unless the event is a double click?
 
> 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?

Well, yes, I've noticed this problem - see gtk_combo_button_release()
for a horrid workaround that I had to do.

My basic feeling is that this issue only comes up when you are
already doing horrid hacks - the GtkCombo case definitely comes
down to that, and I think that your clue hunter case is more
or less a hack too.

The cases where this becomes a problem are cases where a signal that
indicates something that needs to be handled is being abused to be
also a notification single. These are the same places where you
have problems with stuck grabs, you have problems with slight
changes in the widget's internal behavior breaking user code (Think
of all the breakages we have had with event handling in the CLIst.)

Certainly, most cases where people used 'connect_after' in GTK+-1.2
don't work properly now. And in some cases, these cases are
very hard to work around without restructuring the code to do
something quite different.

Basically, the change to TRUE-stops-emits:
 
 - Makes non-hackish code simpler and more reliable
 - Makes unreliable hacks stop work altogether in some places

I would say -- if there isn't a clean way to do what you want to do if
you replace GtkCList with GtkTreeView, then we have a problem that we
need to fix, but I think the idea of using signals that weren't meant
for notification for notification is inherently problematical.

In some cases, it may be that we actually need to add separate
notification signals, where people were previously piggy-backing off
of other signals with connect-after.

Regards,
                                        Owen