Re: why would a default handler ever return true?

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*

 - The ::event-after signal allows for the unusual case where
   you want to do an additional action *after* the default 
   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

   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 

 - 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 


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]