why would a default handler ever return true?

[Stephen Kennedy <stevek gnome org>]

I came across this behaviour when trying to connect to the
mnemonic-activate signal of a label in a notebook tab. The default
handler uses "connect" and stops event propagation. Thus user handlers
never get run.[1]

Here are three common use cases for responding to signals:
1) I want the default behaviour.
2) I want to override the default behaviour.
3) I want default plus additional behaviour (before or after default).

I'm no signals expert, but it seems the following steps are necessary
for the three use cases above. Or perhaps there's an easier way?
1) no action needed.
2) block default handler, install handler.
3) find, remember and disconnect default handler
  a) (before) connect custom, reconnect default
  b) (after) connect a proxy which calls default and returns false
             connect custom handler after

Why don't the builtin signal handlers use "connect_after" and never
stop the signal chain (always return false)? Then we have the much
simpler:
1) no action needed.
2) use connect and return true from handler.
3) use either connect or connect_after depending on need.

Stephen.
-- 
Stephen Kennedy <stevek gnome org>
http://meld.sf.net visual diff and merge

[1] a "connect" before adding the label to the notebook works, but this
approach does not work if the ui is built with glade and the signal
handlers connected in code as in 
http://www.daa.com.au/pipermail/pygtk/2004-June/007798.html