qemu-ppc
[Top][All Lists]
Advanced

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

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


From: Programmingkid
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH v2] Adds the ability to use the command key in the guest operating system.
Date: Sun, 4 Aug 2013 13:53:24 -0400

On Aug 4, 2013, at 5:39 AM, Peter Maydell wrote:

> On 4 August 2013 00:43, Programmingkid <address@hidden> wrote:
>> 
>> On Aug 3, 2013, at 7:06 PM, Peter Maydell wrote:
>> 
>>> On 3 August 2013 23:52, G 3 <address@hidden> wrote:
>>>> This patch adds the ability to use the command key in the guest
>>>> operating system. Just add -command-key 55 to the command line
>>>> options sent to QEMU to use this feature.
>>>> 
>>>> I have checked the patch by sending it thru checkpatch.pl this time. I also
>>>> made a bunch of style changes to more closely match QEMU's suggested coding
>>>> style.
>>>> 
>>>> signed-off-by: John Arbuckle <address@hidden>
>>>> 
>>>> ---
>>>> ui/cocoa.m |  114
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++-----
>>>> 1 files changed, 104 insertions(+), 10 deletions(-)
>>> 
>>> This definitely isn't "trivial".
>>> 
>>> I'm also really unconvinced that this is the right way to handle
>>> this: adding a new cocoa-UI-only command line option which takes
>>> a magic number looks very odd.
> 
>> Why don't you think it is trivial?
> 
> It's over 100 lines long; it's not "obviously correct"; it adds
> a new command line switch; cocoa.m has a listed maintainer.
> 
>> The way of how to handle send the command key into the guest operating
>> system has already been discussed. This way lets the user decide at
>> runtime how best to handle the command key. The magic number you talk
>> about is actually a virtual key value. Every key has their own
>> virtual key.
> 
> 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. Users like me want to use the command key in the guest operating 
system, but we also need to send commands to QEMU. So this causes problems. 
Every user is going to have their own idea on how to solve this problem. So the 
way to fix this problem is to have the user decide which key should act as the 
command key. 

> 
>> 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.

?


reply via email to

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