On Fri, 2004-04-16 at 16:36, John Ehresman wrote: > On Fri, 16 Apr 2004, Owen Taylor wrote: > > > The solution is probably to send an event to the grabbing window, if there > > > is one, when the app loses focus. The question is which event. One > > > possibility is to send a mouse up event, but that seems like the wrong > > > thing to do since no mouse up event has accually occurred. If another > > > event is chosen, code in gtk and elsewhere will need to be modified to > > > look for the "broken grab" event and act accordingly. > > > > This isn't the right way to do things. The right thing to do is to make > > GtkMenuShell able to function without keyboard and pointer grabs using > > standard focused windows. > > How do you track the mouse and close the menu when the button is released > outside of the window without a grab? The user can use alt-Tab to switch > apps while the mouse button is still pressed. In this case, the app never > gets a mouse up event until it gets the focus again. This is less common > than just using the keyboard, but it can happen. X style implicit grabbing on button press is already handled for Win32; I forget the name of the windows facility that is used. You catch focus out to catch the user alt-tabbing away. > Another problem is that the menu window can't take the focus away from > their parent window because the title bar on the parent window will change > color to indicate that it longer has the focus (this was a bug in gtk at > one point that has since been fixed). A detail that is eminently fixable if we get the event handling right. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part