qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Programmingkid
Subject: Re: [Qemu-devel] [PATCH] ui/cocoa.m: Prevent activation clicks from going to guest
Date: Tue, 24 Nov 2015 11:46:09 -0500

On Nov 24, 2015, at 3:56 AM, Peter Maydell wrote:

> On 24 November 2015 at 03:25, Programmingkid <address@hidden> wrote:
>> 
>> On Nov 23, 2015, at 11:06 AM, Peter Maydell wrote:
>> 
>>> On 22 November 2015 at 01:43, Programmingkid <address@hidden> 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 <address@hidden>
>>> 
>>> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]