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 <programmingk...@gmail.com> 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
