[Top][All Lists]

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

Re: [Qemu-devel] Command-line option to change ungrab key(s)

From: Programmingkid
Subject: Re: [Qemu-devel] Command-line option to change ungrab key(s)
Date: Tue, 14 Nov 2017 08:47:12 -0500

> On Nov 14, 2017, at 2:21 AM, Gerd Hoffmann <address@hidden> wrote:
>  Hi,
>>>>> Would this feature be something you would consider adding to QEMU?
>>>> As context, virt-manager allows customization for the ungrab sequence, and
>>>> so do spice-gtk/gtk-vnc at the API level. So conceptually I think it is
>>>> reasonable for any UI console that is intended as more than just a toy.
>>> Would it make sense to share the virt-viewer/remote-viewer --hotkeys
>>> option format ? (see man remote-viewer / virt-viewer)
>> I think you are referring to information found on this page: 
>> https://www.mankier.com/1/remote-viewer
>> The command-line option for changing hotkey actions would be:
>> --hotkeys=<action1>=<key1>[+<key2>][,<action2>=<key3>[+<key4>]]
>> So this means changing the mouse ungrab would look something like this:
>> --hotkeys=release-cursor=F19 (or some other key)
>> Gerd what you think of this idea?
> Certainly not this way.

Did you have an idea on how something like this should look like? This feature 
would only change the old mouse ungrab keys to a user-specified one. So the 
basic algorithm would be change the text that displays at the top of the QEMU 
window to say (Press <user specified key(s)> to release mouse. Then tell the 
code that looks for the ungrab keys which keys to look out for.

>  The display configuration we have right now is
> pretty messy already.  I want clean this up (draft patch series at
> https://www.kraxel.org/cgit/qemu/log/?h=lupin/display-cmdline), and this
> should be done before adding new stuff.

My original idea was to make a patch that would only change the cocoa.m file. 
I'm thinking you want this code to be elsewhere. Somewhere where other UI code 
like GTK would be able to use. Is that what you prefer?

> Also when making this configurable it should be consistent across all
> user interfaces we have, which surely is a non-trivial amount of work.

I know Cocoa but my lack of GTK experience would not permit me to make a patch 
for that UI code. When you are done with your display configuration work, would 
there even be a need to patch the Cocoa/GTK code? I'm under the impression you 
are trying to consolidate some of the UI code under one file. This does sound 
like a logic move to make. It would help to keep things consistent across 
different hosts.

reply via email to

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