On 01.03.2012 10:52, Anurag Priyam wrote: > On Wed, Feb 29, 2012 at 3:59 PM, Uli Schlachter <[email protected]> wrote: >> On 26.02.2012 05:56, Anurag Priyam wrote: [...] >>> Optionally allowing keygrabbers adds to the complexity of the code. >>> And for what gains? Without keygrabber enabled, you can't even close >>> the menu by pressing 'Escape' key (this is what prompted me to change >>> the default to true). >> >> I guess I wouldn't mind. If it simplifies the code a lot, I'm all settled for >> this. However, I don't really have the time to look closely into this. > > Patch attached. If you like it, let's scrap the previous one > (keygrabber = true by default).
Pushed, thanks. >> Anyone out there who opens up a popup menu, then clicks somewhere else and >> expects the menu to stay open? If yes, speak up now or stay quiet forever! > > Yeah, this is another thing that annoys me. Though I am not sure how > I can fix it. I need to determine that mouse was clicked outside > menu. So maybe I can attach a handler to 'press' signal on mouse, but > if it was not clicked on any visible menu (not sure how to determine > that), then close it? Would need a mouse grabber. When someone dares to click elsewhere, the grabber is stopped and the menu closed. (And the click which caused that is discarded, but that's also what gtk/qt are doing) But yeah, you are right. That'd stop the normal event processing and would force the code to do magic with mouse.object_under_pointer() (which should use the mouse position at the time the event was sent, not the current position, but that API can be fixed relatively easily). Uli -- "Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort?" -- A. P. J. -- To unsubscribe, send mail to [email protected].
