quickly-talk team mailing list archive

[Rick Spencer <rick.spencer@xxxxxxxxxxxxx>]

I don't think many to one is an edge case, as menu items, toolbar
buttons, and context menu items often point to the same signal handler.
That said, I don't think it's super common, and writing signal handlers
that simply invoke other signal handlers is pretty common.

What I don't understand is, why can't we have both? I start out with:

button1_clicked_event(self, widget, data=None):
    #do whatever

Then when I add a menu item for the same functionality, can I not simply
decorate the existing signal handler to tell it to also handle the menu
item?

However, it's not clear to me that the described syntax below would
support that, as menu items are activated, not clicked, and the
decoration appears to be designed to share a common signal. 

So, in sum, I would not want to give up auto-signals, but if done
properly, I think the decorators would be a nice enhancement.

Cheers, Rick

On Thu, 2010-12-09 at 13:34 +0000, tony byrne wrote:
> Hi all
>  There has been an enhancement for gtk.Builder (autosignals by Michael
> Terry) merged into trunk recently. While I was working on a parallel
> branch enhancing gtk.Builder a conflicting design arose. Michael is
> the reviewer for my branch and he suggested throwing this design point
> open to discussion.
> 
>  In BuilderGlue.py.__init__(...)
>  lines 71 to 96 functions as auto-connect-by-name. It walks the
> builders widgets and signals
> and looks for methods like widget_signal_event(...) and calls
> widget.connect(signal, widget_signal_event) for every match. Michael
> likes my variant
> find method on_widget_signal and call widget.connect(signal, on_widget_signal).
> 
>  My branch was, among other things, addressing automating a group of
> widgets to common handler suggestion by jo-erlend on #quickly. The use
> case given was 4 navigation widgets "<<", "<", ">", ">>" connecting to
> a common handler.
> 
> my suggested handler was decorated like this
> http://www.drdobbs.com/web-development/184406073#l9
> and auto-connected-by-decoration
> 
> @ui(["first", "previous", "next", "last"], "clicked")
> def on_navigate(widget):
>     widget_name = get_name(widget)
>     do_navigate(widget_name)
> 
> as a alternative to (auto-connect-by-name)
> 
> def on_navigate(widget):
>     widget_name = get_name(widget)
>     do_navigate(widget_name)
> on_first_clicked=on_navigate
> on_previous_clicked=on_navigate
> on_next_clicked=on_navigate
> on_last_clicked=on_navigate
> 
> Michael stated that many to one is an edge case but I don't agree.
> many to one is in PreferencesDialog now and it is needed for toolbar
> and menu handling.
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~quickly-talk
> Post to     : quickly-talk@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~quickly-talk
> More help   : https://help.launchpad.net/ListHelp