| Message ID | AFC490FB-08DE-4F10-A28B-115DA789FB59@gmail.com |
|---|---|
| State | New |
| Headers | show |
On 22 November 2015 at 01:43, Programmingkid <programmingkidx@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 <programmingkidx@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. thanks -- PMM
On Nov 23, 2015, at 11:06 AM, Peter Maydell wrote: > On 22 November 2015 at 01:43, Programmingkid <programmingkidx@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 <programmingkidx@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. What if we were better than Parallels? Apple's own human interface guidelines state that the activation click should not make any changes to the application.
On Nov 23, 2015, at 11:06 AM, Peter Maydell wrote: > On 22 November 2015 at 01:43, Programmingkid <programmingkidx@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 <programmingkidx@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.
On 24 November 2015 at 03:25, Programmingkid <programmingkidx@gmail.com> wrote: > > On Nov 23, 2015, at 11:06 AM, Peter Maydell wrote: > >> On 22 November 2015 at 01:43, Programmingkid <programmingkidx@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 <programmingkidx@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? thanks -- PMM
On Nov 24, 2015, at 3:56 AM, Peter Maydell wrote: > On 24 November 2015 at 03:25, Programmingkid <programmingkidx@gmail.com> wrote: >> >> On Nov 23, 2015, at 11:06 AM, Peter Maydell wrote: >> >>> On 22 November 2015 at 01:43, Programmingkid <programmingkidx@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 <programmingkidx@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.
diff --git a/ui/cocoa.m b/ui/cocoa.m index 1554331..b75c01e 100644 --- a/ui/cocoa.m +++ b/ui/cocoa.m @@ -669,6 +669,16 @@ QemuCocoaView *cocoaView; mouse_event = true; break; case NSLeftMouseDown: + /* + * This prevents the click that activates QEMU from being sent to + * the guest. + */ + if (!isMouseGrabbed && [self screenContainsPoint:p]) { + [self grabMouse]; + [NSApp sendEvent:event]; + return; + } + if ([event modifierFlags] & NSCommandKeyMask) { buttons |= MOUSE_EVENT_RBUTTON; } else {
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 <programmingkidx@gmail.com> --- ui/cocoa.m | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-)