On Tue, 2004-08-31 at 12:47, Stephen Kennedy wrote: > 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. Various answers here: - The policy is that new signals should almost always be G_SIGNAL_RUN_LAST, because, as you point out, that allows overriding the default behavior much more easily. All the GTK+ event signals are run last. - "Default behavior plus original behavior" is generally wrong for event signals. A button press should be doing *one* thing. - The ::event-after signal allows for the unusual case where you want to do an additional action *after* the default handler. Generally, uses of ::event-after are making unsafe assumptions about what the default handler is doing. We don't guarantee that the mouse bindings for the GTK+ built-in widgets won't change. But the ability is there. - expose event handlers almost always should return FALSE since this is a case where doing two things can make sense. If you find violations of this in GTK+, file a bug. - Making changes to either GObject or the current GTK+ signals simply isn't compatible, so even if things could be done "better", it's not changeable. So, I wontfix'ed your bug on that grounds current GTK+ signals nor changing the behavior of Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part