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

[Peter Maydell]

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?

thanks
-- PMM