[Bug 93249] key event going to display even with keyboard ungrabbed

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Dec 9 06:43:09 PST 2015


https://bugs.freedesktop.org/show_bug.cgi?id=93249

--- Comment #17 from Zeeshan Ali <zeenix at gmail.com> ---
(In reply to Victor Toso from comment #16)
> (In reply to Christophe Fergeau from comment #14)
> > (In reply to Jonathon Jongsma from comment #13)
> > > (In reply to Victor Toso from comment #11)
> > > > IMHO, if the user does not want the key to go to boxes after ctrl_l+alt_l he
> > > > should switch the focus to the target app, where they key should go.
> > > > (ctrl_l+alt_l then alt+tab works with remote-viewer here)
> > > 
> > > 
> > > Well, as far as I know, it's also important for accessibility within the
> > > application itself, not just between different apps. But it works for me
> > > here as well. And not just Alt+tab. If I release the grab in virt-viewer (by
> > > pressing ctrl_l+alt_l), I can now press Alt+F and the virt-viewer "file"
> > > menu opens. So that seems to be the behavior Zeeshan was requesting.
> > 
> > My understanding is that this indeed is all about what happens after the
> > ungrab combo is pressed (see
> > http://cgit.freedesktop.org/spice/spice-gtk/commit/
> > ?id=767e5522f64c115f66f6419abd378ad568e5564e ). After the combo has been
> > pressed, I'd expect all keys to go to the client rather than the guest until
> > the mouse moves (or is clicked?), or until the combo is pressed again.
> 
> Pavel's commit mentions exactly for keyboard shortcuts after ungrab combo.
> 
> If we change the behavior to ignore any keyboard input after ungrab combo,
> it might be the case that user's typing will be lost till he realize that he
> must move the mouse or do the UNgrab combo to grab it.

* Apps can help with that. E.g Boxes already shows a label in topbar and we
could grey out/disable the guest display widget or replace it with another
widget when keyboard is ungrabbed. There are many things that could be done to
ensure user knows keyboard is currently grabbed.

* Maybe we should consider using a combo that is harder to hit by accident?
It's not very hard to hit Ctrl_L and Alt_L together by accident. Maybe
Ctrl_L+Alt_L+g ?

> I mean, the current behavior already is that if you do ungrab combo then
> alt+tab to another app, then alt+tab back, it will not grab the keyboard
> back but I still can type and keyboard input will go to target app in guest.
> 
> If we change the behavior, I would expect at least that after alt+tab back
> to app, I can type to the guest without typing any combo.

Sure, we could change that behaviour.

> (In reply to Zeeshan Ali from comment #15)
>  mouse moves (or is clicked?), or until the combo is pressed again. 
> > Bingo!
> 
> Yes! But please don't be lazy next time? irc chat is just a complement to
> bug description. ;)

I don't agree. Unless the chat is long and it's hard to follow (which IMO it is
not the case here at all), I don't see the point of going through the whole
discussion of "oh, you mean this and not that" all over again.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-bugs/attachments/20151209/594f51d0/attachment.html>


More information about the spice-bugs mailing list