Lorenzo Gil Sanchez <[EMAIL PROTECTED]> writes: > Talking about Gazpacho I'll share with you the way I plan to implement > signal_autoconnect in Gazpacho: > > 1. First check if there is a method named > [on|after]_widgetname__signalname and if so connect the signal > 'signalname' to the widget 'widgetname' > > 2. Then check if the glade file has any signal definition (specified in > Gazpacho signal editor) and then also connect these. > > So basically, we wouldn't need the signal editor and all connection > could be done from the source code of the user program. Why don't > removing Gazpacho signal editor?. Well I can think on at least one > scenario where it could be usefull: connecting two signals of two > different objects to the same signal handler.
Good point. I haven't often needed to connect signals from different widgets to the same handler, but I've done it two ways when necessary. Either do the connection by hand in the controller __init__() method or simply delegate from one handler to the other by calling it. Sometimes connection by hand in __init__() will be necessary anyway because you want to connect to a widget that doesn't appear in the glade file. This happens a lot with textbuffers in textviews and with treeview selections. I think I remember reading a comment by Damon Chaplin that he wanted to change glade to expose these widgets but I'm not sure how that would work. Gazpacho uses a checkbox on the Editor signal page to specify signal connection using connect_after() instead of connect(). That doesn't seem to allow specifying two handlers for the same widget, one to connect and the other to connect_after. Since this is rarely needed and it's easy to do by hand I don't see the need to clutter Gazpacho's GUI to allow doing this directly. _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
