<div class="gmail_quote">On Sun, Oct 7, 2012 at 3:46 PM, Pekka Vuorela <<a href="mailto:pvuorela@iki.fi" target="_blank">pvuorela@iki.fi</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="HOEnZb"><div class="h5">On su, 2012-10-07 at 15:12 -0600, Scott Moreau wrote: > > > On Sun, Oct 7, 2012 at 12:21 PM, Pekka Vuorela <<a href="mailto:pvuorela@iki.fi">pvuorela@iki.fi</a>> > wrote: > On su, 2012-10-07 at 04:28 -0600, Scott Moreau wrote: > > Don't send motion events to the surface when the pointer is > not over the menu. > > This was also causing items to be selected when clicking > outside of the menu. > > > Wouldn't it be quite a lousy grab if only events on top of the > grabbing > window would be delivered? > > > Is there another way to determine this information from client side? > > </div></div>Client knows the width of the menu and can ignore events based on that. I was actually checking out why menu handling doesn't work properly a week ago and came across few other issues. First, it's not doing a real grab even though wl_shell_surface::set_popup defines one. Events only passed on top of client's surfaces. Second, mouse on top of main window passes events with coordinates relative to that.</blockquote><div> The x/y we get when outside of the menu surface are relative to the parent. So there's no way currently to tell from client side whether or not the motion event is on the parent or child. I'm not sure why you'd need a grab here, unless you wanted to be able to drag a menu for some reason. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Created a bug report for those <a href="https://bugs.freedesktop.org/show_bug.cgi?id=55325" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=55325</a> </blockquote></div>