<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - key event going to display even with keyboard ungrabbed" href="https://bugs.freedesktop.org/show_bug.cgi?id=93249#c7">Comment # 7</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - 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:zeenix@gmail.com" title="Zeeshan Ali <zeenix@gmail.com>"> Zeeshan Ali</a> <pre>(In reply to Marc-Andre Lureau from <a href="show_bug.cgi?id=93249#c6">comment #6</a>) > (In reply to Zeeshan Ali from <a href="show_bug.cgi?id=93249#c5">comment #5</a>) > > > This is similar to any other gtk > > > widget. > > > > Except that in case of other gtk widget, you can use kbd nav to switch to > > other widgets, e.g with 'Tab' key. > > Not all widgets though. If I take textview or vte widget for example (which > should be similar to spice widget), it seems you can't change the focus with > TAB, and for good reasons. Yes and I'm not saying TAB should work when keyboard is grabbed. > And they don't always have a key combination to > prevent this. In case of textview it's ctrl+tab. Yeah, they are provided if needed but 'Tab' is just an example. Not sure about vte but gnome-terminal in specific doesn't really need that. Keyboard shortcuts for terminal app work fine even when terminal widget is in focus. > > > It would be very unconvenient to explicitely take the grab in order > > > to give input to this widget. > > > > Seems you are talking about the opposite. I'm talking about the state of > > user explicitly ungrabbing kbd using Ctrl_L+Alt_L keys and then expecting > > all key event to go to client/host while kbd is ungrabbed. At the very least > > they should have a way to focus another widget using 'Tab' key. > > Probably not. Ungrabbing is for special keys, and tab is not special. Well I think it should not be for special keys only. We tell user that keyboard is ungrabbed, which is already a bit cryptic. Now I really don't want to explain to them that we only mean special keys cause that's what SPICE want to mean by ungrabbing. > > If you insist on Boxes implementing this, I don't mind at all doing it there > > but then spice needs to provide me the way to distinguish between user > > explicitly ungrabbing keyboard and it happening as a result/side-effect of > > some other action/event. > > I don't understand precisely the use case here. > > Is it about being able to change the widget focus from keyboard? As I already tried to explain, as a user I expect key event to be received by client/host until keyboard is grabbed again. Switching focus is just a step users will typically want to go for after ungrabbing. It could be that they want to hit some key combos (e.g F11 for fullscreening or Alt+Left to go back to overview). > This is problematic, because it will prevent sending this particular input > to the guest. Yes and I don't see why that is a problem since user explicitly asked for keyboard to be ungrabbed and keys going to the guest is exactly the opposite of what they should expect. > You can do this in boxes in various ways. It's not necessary for spice-gtk > to provide this, and imho it's better left outside, since it will need to be > configured for various needs (all key bindings are done in virt-viewer for > ex, except ungrab, which is mostly for historical reasons) As long as SPICE is handling the keyboard ungrab, this really should be handled by SPICE. Please do let me know some of the possible ways I can solve this in Boxes. I can kinda work around the issue by Boxes taking the focus to toolbar's buttons when keyboard in ungrabbed but I already explained above how I don't see how to do that without spice telling me what ungrabbed keyboard. Also, I doubt user expects focus to be moved just cause keyboard was ungrabbed.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>