Re: [gtk-vnc-devel] PATCH: make keyboard & pointer grabs configurable

On Mon, Jul 09, 2007 at 04:38:56PM +0200, Gerd Hoffmann wrote:
> Daniel P. Berrange wrote:
> > On Mon, Jul 09, 2007 at 11:00:02AM +0200, Gerd Hoffmann wrote:
> >> I wouldn't separate these two for usability reasons.  Input (both kbd
> >> and mouse) should either be grabbed or not grabbed (and the grab state
> >> should be clear to the user, but that isn't the job of the widget but
> >> the using apps I guess).
> > 
> > There is no reason to grab the mouse if the guest OS is operating in 
> > absolute pointer mode - eg if using a USB tablet, or if you have configured
> > the X server to use Xen's paravirt mouse with evdev.
> It may be convinient even in absolute pointer mode, for example to reach
> the $desktop panel by just going quickly up/down until the mouse pointer
> reaches the virtual screen border (but doesn't go across into another
> window).  You can work without grab though, which is almost impossible
> in relative mode.
> > You may still want to grab the keyboard whenever the mouse is over the
> > widget though, so that window manager short cuts get seen by the guest
> > instead of the host. I don't want to have my mouse constrained to the
> > window just so that keyboard shortcuts work.
> Never bothered me much.  Keyboard getting all keystrokes with the grab
> is important for keyboard-oriented GUI work (Alt-Letter -> Menu, jump
> around in dialog boxes, ...).  If I do that I usually don't care much
> what the mouse does.  For most normal typing you don't need a grab though.
> >>> this to add 'Press Ctrl+Alt to release pointer' to the title bar.
> >> One of the obvious reasons for that is that there is one "release grab"
> >> hotkey only.
> > 
> > Two primary scenarios I have
> > 
> >   - Grab both  keyboard & mouse at same time - upon first click - in this
> >     case there's  only a single ungrab hotkey needed
> I suggest to *allways* grab both.  I think this is what qemu and vmware
> do too, so people are used to it (and also to the Ctrl-Alt release).
> Make configurable which events actually trigger the grab (explicit user
> request via menu / hotkey, implicit by keypress / mouse button, ...).
> >   - Grab keyboard only when mouse is over the VNC widget - there's no
> >     ungrab hotkey needed at all - simply move the mouse outside the
> >     widget
> That can be _very_ annonying.  I sometimes have guests fullscreen, each
> on a virtual desktop, then use window manager desktop switch hotkeys to
> switch from one guest to another, to firefox on the host, ...
> That would work very badly if I would be forced to move the mouse out of
> the window just to have WM hotkeys work.
> At very minimum the "release" hotkey has to work unconditionally.  No
> matter what the grab is, Ctrl-Alt will release it.  But I'd prefere to
> not separate mouse/keyboard grabs.

This whole discussion says to me that there's no one solution that would
make everyone happy, so having the flexibility in the API to change the
mode of operation is worthwhile - both traditional vncviewer client and
virt-manager allow you to define the circumstances under which grab occurs
I think the API should be enough to cope with the different use cases 
mentioned in this thread, but I'll double check again.

|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules:              -=|
|=-               Projects:               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

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