qemu-trivial
[Top][All Lists]
Advanced

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

Re: [Qemu-trivial] [Qemu-ppc] [Qemu-devel] [PATCH v2] Adds the ability t


From: Alexander Graf
Subject: Re: [Qemu-trivial] [Qemu-ppc] [Qemu-devel] [PATCH v2] Adds the ability to use the command key in the guest operating system.
Date: Wed, 14 Aug 2013 20:02:16 +0200

On 04.08.2013, at 20:52, Programmingkid wrote:

> 
> On Aug 4, 2013, at 2:07 PM, Peter Maydell wrote:
> 
>> On 4 August 2013 18:53, Programmingkid <address@hidden> wrote:
>>> On Aug 4, 2013, at 5:39 AM, Peter Maydell wrote
>>>> Right, but I don't have to specify anything about any other
>>>> key on the keyboard, why should command be special?
>>> 
>>> The command key is used to send commands to an application. When
>>> the user runs Mac OS X in QEMU, and the host operating system is
>>> Mac OS X, this can cause problems.
>> 
>> Yes, I understand the problem. Why is this any different to
>> the similar issue with the menu-key or the Windows key in Windows
>> (where you also might want to pass it through to the guest,
>> or have it handled outside the guest).
> 
> I don't use QEMU on a PC, so I don't have experience with this issue. But it 
> does sound like the problem I had on Mac OS X. For anyone who uses QEMU on 
> Windows, is the control key used to send commands to QEMU, and sent to the 
> guest operating system? I'm wondering if someone out there uses a Windows 
> guest on a Windows host can help us with this issue. 
> 
>> 
>>>>> Do you have your own idea as to how to handle the command key?
>>>> 
>>>> "Should the QEMU UI use the menu-accelerator key for menus or
>>>> should it pass it through to the guest" is a generic UI front-end
>>>> problem; any solution should not be specific to a single UI,
>>>> we should handle it the same way for all front-ends.
> 
> The problem with this idea is each UI has its own implementation library: 
> SDL, GTK, Cocoa. Each UI would have to have its solution coded differently. 
> There is no one size fits all solution. I honestly don't know if this is an 
> issue with the SDL and GTK UI's. 

The argument is that the user experience and configuration methods should be as 
close as possible / reasonable across the different UI backends.


Alex




reply via email to

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