> >However, mnemonic-activate is not fired if I connect to it after adding
> >the tab. It's work-aroundable in code but obviously breaks with glade.
> >See the attached test case.
> >
> >
> The notebook's internal "mnemonic-activate" handler stops handlers
> connected after it from being activated.
I've come across this before (pygtk Digest, Vol 1, Issue 939) and this
kind of builtin behaviour still baffles me. It just seems needlessly
complex.
Here are three common use cases for signals:
1) I want the default behaviour.
2) I want to override the default behaviour.
3) I want default plus additional behaviour.
Currently 2 and 3 are quite complex. Or perhaps there's an easier way?
1) no action needed.
2) find and disconnect 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
IMHO the builtin signal handlers should use "connect_after" and never
stop the signal chain. Then:
1) no action needed.
2) use connect and return true from handler.
3) use either connect or connect_after depending on need.
Any gtk hackers care to comment?
Stephen.
--
Stephen Kennedy <[EMAIL PROTECTED]>
http://meld.sf.net visual diff and merge
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
