<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - key event going to display even with keyboard ungrabbed" href="https://bugs.freedesktop.org/show_bug.cgi?id=93249#c26">Comment # 26</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - key event going to display even with keyboard ungrabbed" href="https://bugs.freedesktop.org/show_bug.cgi?id=93249">bug 93249</a> from <a class="email" href="mailto:jonathon@quotidian.org" title="Jonathon Jongsma <jonathon@quotidian.org>"> Jonathon Jongsma</a> <pre>(In reply to Victor Toso from <a href="show_bug.cgi?id=93249#c25">comment #25</a>) > > > The issue here is has_focus + ungrabbed case. Like I said before, If user > > > explicitly requested keyboard ungrab (and provided spice and/or App does > > > make sure user knows keyboard in ungrabbed currently), all key events should > > > really go to client/host and none to guest. > > > > so you want 4th state (I wish you explained this a bit more clearly from the > > start) > > Indeed :) > > > > > - after ungrab, the widget should take no input == loose the focus > > > > Imho this does't make sense, how would you get back to the focus state? I > > really this would be confusing for the user. > > Not loose focus, no. He is suggesting that: > 1-) Boxes has focus and you are typing into Gedit inside guest > 2-) ungrab combo is pressed > 3-) no key should go to the guest, but Boxes still hold focus > > User can either alt+tab out and alt+tab back to have focus+keyboard-grab or > just hit the ungrab combo to be able to send keys to Gedit in the guest. Are you suggesting that the focus should be moved to a different widget within the Boxes application after ungrabbing? Or would the Spice display widget still have focus, but would be in a state where it blocks all input? I agree with Marc-Andre: I don't think that a 4th state really makes sense here. I think that when you ungrab, the widget should still have focus, and behave in the same way as the second state mentioned in <a href="show_bug.cgi?id=93249#c21">comment 21</a>. This means that any global hotkeys (e.g. Alt+Tab) or application shortcuts (e.g. Alt+F) will be handled by the client application or desktop, but any other keys will be handled normally by the SpiceDisplay widget (which will redirect them to the guest). This works right now. The original problem description was this: <zeenix> In Boxes, user would expect the kbd shortcuts to topbar buttons to work when they ungrab kbd but seems all events (but system ones, e.g super key) still goes to display And as I've mentioned above, this actually does work already in virt-viewer. So if it doesn't work in boxes, it's probably either a boxes bug, or you're using an old version of spice-gtk without the fix christophe mentioned. As for the potential UI mentioned in <a href="show_bug.cgi?id=93249#c21">comment 21</a>, There is a SpiceDisplay::keyboard-grab signal. As far as I can tell, that should satisfy your use case. So I personally think this bug should be closed.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>