On Nov 24, 2015, at 3:56 AM, Peter Maydell wrote:
> On 24 November 2015 at 03:25, Programmingkid
> wrote:
>>
>> On Nov 23, 2015, at 11:06 AM, Peter Maydell wrote:
>>
>>> On 22 November 2015 at 01:43, Programmingkid
>>> wrote:
When QEMU is brought to the foreground, the click event that
On 24 November 2015 at 03:25, Programmingkid wrote:
>
> On Nov 23, 2015, at 11:06 AM, Peter Maydell wrote:
>
>> On 22 November 2015 at 01:43, Programmingkid
>> wrote:
>>> When QEMU is brought to the foreground, the click event that activates QEMU
>>> should not go to the guest. Accidents happen
On Nov 23, 2015, at 11:06 AM, Peter Maydell wrote:
> On 22 November 2015 at 01:43, Programmingkid
> 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 cha
On Nov 23, 2015, at 11:06 AM, Peter Maydell wrote:
> On 22 November 2015 at 01:43, Programmingkid
> 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 cha
On 22 November 2015 at 01:43, Programmingkid 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.
> Wind
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. Thi
