[Qemu-devel] [PATCH] ui/cocoa.m: Prevent activation clicks from going to guest

[Qemu-devel] [PATCH] ui/cocoa.m: Prevent activation clicks from going to guest

[Programmingkid]

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(-)

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 {
-- 
1.7.5.4

Re: [Qemu-devel] [PATCH] ui/cocoa.m: Prevent activation clicks from going to guest

[Peter Maydell]

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

Re: [Qemu-devel] [PATCH] ui/cocoa.m: Prevent activation clicks from going to guest

[Programmingkid]

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.

Re: [Qemu-devel] [PATCH] ui/cocoa.m: Prevent activation clicks from going to guest

[Programmingkid]

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.

Re: [Qemu-devel] [PATCH] ui/cocoa.m: Prevent activation clicks from going to guest

[Peter Maydell]

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

Re: [Qemu-devel] [PATCH] ui/cocoa.m: Prevent activation clicks from going to guest

[Programmingkid]

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.