qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2] Adds the ability to use the comma


From: Anthony Liguori
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v2] Adds the ability to use the command key in the guest operating system.
Date: Wed, 14 Aug 2013 15:44:20 -0500

I'm confident there's a way to get hardware keycodes on OS X.  There
is on every other UI platform that I know of.  That's the best way to
solve this.

Regards,

Anthony Liguori

On Wed, Aug 14, 2013 at 1:02 PM, Alexander Graf <address@hidden> wrote:
>
> 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]