On Nov 24, 2015, at 3:56 AM, Peter Maydell wrote: > On 24 November 2015 at 03:25, Programmingkid <programmingk...@gmail.com> > wrote: >> >> On Nov 23, 2015, at 11:06 AM, Peter Maydell wrote: >> >>> On 22 November 2015 at 01:43, Programmingkid <programmingk...@gmail.com> >>> wrote: >>>> When QEMU is brought to the foreground, the click event that activates QEMU >>>> should not go to the guest. Accidents happen when they do go to the guest >>>> without giving the user a change to handle them. Buttons are clicked >>>> accidently. >>>> Windows are closed accidently. Volumes are unmounted accidently. This patch >>>> prevents these accidents from happening. >>>> >>>> Signed-off-by: John Arbuckle <programmingk...@gmail.com> >>> >>> So, I checked how Parallels behaves (this is my go-to check for >>> "how should a native OSX VM window behave?"), and it works the >>> same way QEMU does -- left mouse clicks "click through" so they >>> both raise the window to the front and have the behaviour >>> indicated by the guest OS. >> >> But doesn't Parallels allow you to move the mouse pointer before activating >> it? >> QEMU requires the mouse to be grabbed before any movement can take >> place. That makes moving the mouse pointer out of danger before an activation >> click impossible. > > I'm not entirely sure what you mean. Parallels doesn't show a separate > guest mouse pointer generally: where you click the host mouse pointer > is where the click happens. You can choose where in the guest window you > want to make the activation-and-clickthrough click. > > Ah, I think I've just worked it out -- when there's no guest OS > support for absolute mouse positioning (ie you're using an emulated > mouse rather than emulated tablet for input), the guest mouse pointer > will just be wherever in the guest window it was left (perhaps even > underneath the obscuring window), so we will effectively click on that > point, not on wherever the user actually made the activating click. > OK, I'm convinced, we should definitely not do that. > > I asked somebody to check VMWare's behaviour as another > data point. Apparently it doesn't do click-through > to the guest window, but it doesn't pass through the > right mouse button either. Your patch only affects leftclicks: > should we suppress other mouse events too?
Suppressing other mouse events does sound logical. Another patch will be made to do this.