I'm responding with a few things to check on. I don't have a two button mouse, so I did my testing with the left-click and then changed it before committing, but then realized that there could be complications:
1) If the event handler for the widget/button gets called before that of the invoker, then the button behavior will be invoked even on right-click, which is undesirable. We might need to change the connections on the various widgets to connect-after, or alternately verify within the current handlers that event.button == 1. These changes could be a separate patch, for clarity. 2) I didn't return False from the event handler in the WidgetInvoker class, which means regardless of (1), right-clicking on toolbar buttons/frame elements could be broken. If this is the case, this should be fixed in the current patch. - Eben On Fri, May 23, 2008 at 9:19 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: > This does the first half of the work, revealing the palette > immediately upon right click. It doesn't handle the dismissal > correctly. (It can be dismissed on roll-out, rather than explicitly. > I wonder if it matters...) Anyway, my only real question about the > patch is whether there is a meaningful constant for the right mouse > button; I couldn't find one, but checking with '== 3' feels unclean. > > - Eben > _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
