Bug 93249

(no thanks for this long and confusing irc log)

When not grabbing, spice-gtk display receive all events from gtk, like any other widgets that has the focus.

If your application want to have extra keyboard handling, it must do so via focus management or accelerators, or event filter etc. I don't think spice-gtk widget should change its default behaviour, it's a regular gtk widget.

(In reply to Marc-Andre Lureau from comment #1)
> (no thanks for this long and confusing irc log)

My assumption was that fidencio or jjongsma shall be looking at this bug since they were the ones replying on IRC and showing interest.

> When not grabbing, spice-gtk display receive all events from gtk, like any
> other widgets that has the focus.
> 
> If your application want to have extra keyboard handling, it must do so via
> focus management or accelerators, or event filter etc. I don't think
> spice-gtk widget should change its default behaviour, it's a regular gtk
> widget.

This is *not* "extra keyboard handling", when I ungrab the keyboard as user, I expect all key events to be going to host, regardless of which app I'm using. Can't spice-gtk ignore all key events during keyboard ungrab, perhaps by simply returning false from event handlers?

(In reply to Zeeshan Ali from comment #2)
> This is *not* "extra keyboard handling", when I ungrab the keyboard as user,
> I expect all key events to be going to host, regardless of which app I'm
> using. Can't spice-gtk ignore all key events during keyboard ungrab, perhaps
> by simply returning false from event handlers?

You don't need a keyboard grab to be able to use a remote spice (most of the time you don't want the grab I would say). This is similar to any other gtk widget. It would be very unconvenient to explicitely take the grab in order to give input to this widget.

fwiw, there is a "disable-input" property that remove focus from the widget and disable all input to the widget. Imho, this is really not what you want, but you may want to play with this. Alternatively, you could just set_can_focus() yourself in the app.

(In reply to Marc-Andre Lureau from comment #3)
> (In reply to Zeeshan Ali from comment #2)
> > This is *not* "extra keyboard handling", when I ungrab the keyboard as user,
> > I expect all key events to be going to host, regardless of which app I'm
> > using. Can't spice-gtk ignore all key events during keyboard ungrab, perhaps
> > by simply returning false from event handlers?
> 
> You don't need a keyboard grab to be able to use a remote spice (most of the
> time you don't want the grab I would say).

? remote spice? I don't this.

> 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.

> 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.

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.

(In reply to Zeeshan Ali from comment #5)
> > 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. And they don't always have a key combination to prevent this. In case of textview it's ctrl+tab.

> > 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.

> 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?

This is problematic, because it will prevent sending this particular input to the guest.
 
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)

(In reply to Marc-Andre Lureau from comment #6)
> (In reply to Zeeshan Ali from comment #5)
> > > 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.

(In reply to Zeeshan Ali from comment #7)
> 
> 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.

Well, FWIW, VNC has the same behavior (so, most likely not a SPICE problem).

(In reply to Fabiano Fidêncio from comment #8)
> (In reply to Zeeshan Ali from comment #7)
> > 
> > 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.
> 
> Well, FWIW, VNC has the same behavior (so, most likely not a SPICE problem).

That doesn't make it a non-bug. :) By VNC, I'm guessing you mean a particular implementation: gtkvnc, right? So if this is an issue, it exists in both software.

(In reply to Zeeshan Ali from comment #7)
> (In reply to Marc-Andre Lureau from comment #6)
> > (In reply to Zeeshan Ali from comment #5) 
> > > > 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.

Also:

* SPICE docs mention nothing about keyboard ungrab/grab being specific to special keys/combos.

* As user of spice-gtk API, I would expect keyboard ungrab to be not very different from mouse ungrab. Since mouse ungrab means all mouse events going to host/client, I don't see why keyboard grab should work any differently.

> Also:
> 
> * SPICE docs mention nothing about keyboard ungrab/grab being specific to
> special keys/combos.
> 
> * As user of spice-gtk API, I would expect keyboard ungrab to be not very
> different from mouse ungrab. Since mouse ungrab means all mouse events going
> to host/client, I don't see why keyboard grab should work any differently.

So, If I understood correctly:

Current behavior:
ctrl_l+alt_L then press any keyboard key. The key goes to the guest.

Expected behavior (by reporter):
after ctrl_l+alt_l, no keyboard key should go to guest (until...?)

If this is correct, I wish this thread have started like this.

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)

Indeed, we could improve SPICE docs...

If I understand correctly, what Zeeshan request is that input don't go to the display, unless the grab has been explicitely taken. 

This would be unfriendly. We want the spice widget to be an input widget, when it has the focus, it takes the input, like any input widget (text, terminal etc), without extra initial key combination.

Now, if an app needs a keybinding to change the focus on a different widget, it can do so itself. There is no need for a change of behaviour or extra API here.

(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.

(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.

(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.

Bingo!

(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.

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.

alt+tab + typing is something I do with lots of different applications. Doing alt+tab+(grab combo) would be annoying.

(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. ;)

(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.

(In reply to Zeeshan Ali from comment #17)
> (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.

BTW, SPICE could handle that as well and IMO it probably should but I'm happy if this bug is fixed and won't want to push my luck. :)

(In reply to Zeeshan Ali from comment #17)

> * 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 ?

You may certainly choose a different ungrab key in boxes. It's configurable. virt-viewer provides a commandline option for specifying it.



(In reply to Zeeshan Ali from comment #18)
> BTW, SPICE could handle that as well and IMO it probably should but I'm
> happy if this bug is fixed and won't want to push my luck. :)

I think Christophe already pointed you to the commit that fixed this issue...

(In reply to Jonathon Jongsma from comment #19)
> (In reply to Zeeshan Ali from comment #17)
> 
> > * 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 ?
> 
> You may certainly choose a different ungrab key in boxes. It's configurable.
> virt-viewer provides a commandline option for specifying it.
> 
> 
> 
> (In reply to Zeeshan Ali from comment #18)
> > BTW, SPICE could handle that as well and IMO it probably should but I'm
> > happy if this bug is fixed and won't want to push my luck. :)
> 
> I think Christophe already pointed you to the commit that fixed this issue...

I'm sure, you completely misunderstood me. In the quoted context that you didn't paste, I was talking about showing some UI to ensure user knows keyboard is grabbed not wonder if keyboard is not working after (potentially accidently) hitting the keyboard ungrab combo. I doubt SPICE does that already.

(In reply to Zeeshan Ali from comment #20)
> I'm sure, you completely misunderstood me. In the quoted context that you
> didn't paste, I was talking about showing some UI to ensure user knows
> keyboard is grabbed not wonder if keyboard is not working after (potentially
> accidently) hitting the keyboard ungrab combo. I doubt SPICE does that
> already.

I fail to understand that. spice-gtk input behaviour is rather simple:
- has no focus -> no input
- has focus -> gtk input is handled by the widget
- has focus + grab -> all keyboard input (including "system keys", except vt-switch) is handled by the widget

When the widget has the focus, there is no handling of focus chain built-in the widget, but like any other accelerator, you can set one in your app.

(In reply to Marc-Andre Lureau from comment #21)
> (In reply to Zeeshan Ali from comment #20)
> > I'm sure, you completely misunderstood me. In the quoted context that you
> > didn't paste, I was talking about showing some UI to ensure user knows
> > keyboard is grabbed not wonder if keyboard is not working after (potentially
> > accidently) hitting the keyboard ungrab combo. I doubt SPICE does that
> > already.
> 
> I fail to understand that.

I'm not sure about the relevance of the quoted text above to what you are saying below.

> spice-gtk input behaviour is rather simple:
> - has no focus -> no input
> - has focus -> gtk input is handled by the widget

And this is normal for most widget which do not need the concept of 'keyboard grab'.

> - has focus + grab -> all keyboard input (including "system keys", except
> vt-switch) is handled by the widget

That is fine too.

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.
 
> When the widget has the focus, there is no handling of focus chain built-in
> the widget, but like any other accelerator, you can set one in your app.

I don't know what you mean. Boxes has accelerators for display state but they currently don't work even when keyboard is ungrabbed and that's the issue here.

(In reply to Zeeshan Ali from comment #22)
> (In reply to Marc-Andre Lureau from comment #21)
> > spice-gtk input behaviour is rather simple:
> > - has no focus -> no input
> > - has focus -> gtk input is handled by the widget
> 
> And this is normal for most widget which do not need the concept of
> 'keyboard grab'.

what does this have to do with 'keyboard grab'? there are 3 states here, and you seem to agree they make sense. 

> 
> > - has focus + grab -> all keyboard input (including "system keys", except
> > vt-switch) is handled by the widget
> 
> That is fine too.
> 
> 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)

- 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.

Anyway, you can experiment with this in Boxes, when the keyboard grab is lost, you can just change the focus to another widget.

> > When the widget has the focus, there is no handling of focus chain built-in
> > the widget, but like any other accelerator, you can set one in your app.
> 
> I don't know what you mean. Boxes has accelerators for display state but
> they currently don't work even when keyboard is ungrabbed and that's the
> issue here.

It should work, it works with virt-viewer.

(In reply to Zeeshan Ali from comment #17)
> * 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 ?

You mean because ctrl+alt+del? It shouldn't be a problem IMHO.

> > (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.

Well, first thing, you said you were lazy in comment #0 :-)

I think it wasn't clear enough, really. Your "Bingo!" in comment #15 was after some discussion just to understand what behavior you would like to change. I would rather that this was on comment #0 and the focus of our discussion was why/how agree/disagree.

(In reply to Zeeshan Ali from comment #18)
> BTW, SPICE could handle that as well and IMO it probably should but I'm
> happy if this bug is fixed and won't want to push my luck. :)

Right. Pavel is back next week and I would love to hear what he thinks about it as well... I'm probably missing something

> > 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.

> 
> Anyway, you can experiment with this in Boxes, when the keyboard grab is
> lost, you can just change the focus to another widget.
> 
> > > When the widget has the focus, there is no handling of focus chain built-in
> > > the widget, but like any other accelerator, you can set one in your app.
> > 
> > I don't know what you mean. Boxes has accelerators for display state but
> > they currently don't work even when keyboard is ungrabbed and that's the
> > issue here.
> 
> It should work, it works with virt-viewer.

Hmm..

(In reply to Victor Toso from comment #25)
> > > 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 comment 21. 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 comment 21, 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.

I'm not sure why you guys are so confused. The title of this bug and first few sentences of chat log should have been enough. Is it possible that none of you cared to read the chat? In which case we were all being lazy, except for Christophe. :)

If I didn't explain well in comment#0, I most definitely explained in later comments in great detail what exactly I'm expecting to happen. If not, Christophe's comment (to which, I said "Bingo") should have been enough. But let me trt again:

* I do not want the focus to move somewhere else on keyboard ungrab. How would spice-gtk widget know where to send the focus to anyway? How would it get it back if next thing user does after ungrabbing is to grab again (change their mind)? So no, I didn't ask for that at all.

* What I'm asking for is keyboard-grab=false to work as expected. i-e No key events sucked by spice display when keyboard in ungrabbed even if widget is in focus. No, this is not a new state I'm asking for. It's what keyboard-unpgrab is meant for and it partially works (for system keys).

Now, as for it working in virt-viewer as expected, I do not see the expected behaviour in virt-manager either. I tried:

1. Ungrab kbd
2. Hit Ctrl+q (nothing happened)
3. Ungrab kbd again
4. Hit Ctrl+w (nothing happened)
5. Ungrab kbd again
6. Hit Ctrl+w (nothing happened)
7. Ungrab kbd again
8. Hit F11 (nothing happened)
9. Ungrab kbd again
10. Tab to switch focus (focus remained on display and got a kbd bell from terminal inside the guest demonstrating that key was received by guest)

So I really don't think keyboard-ungrab is working as expected in any SPICE app.

(In reply to Zeeshan Ali from comment #27)
> Is it possible that none
> of you cared to read the chat? In which case we were all being lazy, except
> for Christophe. :)

I did not read the chat, and agree with others that it's bad from, and that the usual steps to reproduce/expected result/observed result would have made everything much clearer from the start.

(In reply to Zeeshan Ali from comment #27)
> * What I'm asking for is keyboard-grab=false to work as expected. i-e No key
> events sucked by spice display when keyboard in ungrabbed even if widget is
> in focus. No, this is not a new state I'm asking for. It's what
> keyboard-unpgrab is meant for and it partially works (for system keys).

keyboard-ungrab is generally for system grab (nothing else by default) 

> Now, as for it working in virt-viewer as expected, I do not see the expected
> behaviour in virt-manager either. I tried:
> 
> 1. Ungrab kbd
> 2. Hit Ctrl+q (nothing happened)

It's ctrl+shift+q, and you need to press ctrl+alt.

> 3. Ungrab kbd again
> 4. Hit Ctrl+w (nothing happened)
> 5. Ungrab kbd again
> 6. Hit Ctrl+w (nothing happened)

what's ctrl+w?

> 7. Ungrab kbd again
> 8. Hit F11 (nothing happened)

and all this work for me

> 9. Ungrab kbd again
> 10. Tab to switch focus (focus remained on display and got a kbd bell from
> terminal inside the guest demonstrating that key was received by guest)

there is no accelerator or handling of Tab or focus management in virt-viewer.

> 
> So I really don't think keyboard-ungrab is working as expected in any SPICE
> app.

It does.

(In reply to Marc-Andre Lureau from comment #29)
> (In reply to Zeeshan Ali from comment #27)
> > * What I'm asking for is keyboard-grab=false to work as expected. i-e No key
> > events sucked by spice display when keyboard in ungrabbed even if widget is
> > in focus. No, this is not a new state I'm asking for. It's what
> > keyboard-unpgrab is meant for and it partially works (for system keys).
> 
> keyboard-ungrab is generally for system grab (nothing else by default) 

Currently that might be but I presented arguments of why it should be for all keys, above.
 
> > Now, as for it working in virt-viewer as expected, I do not see the expected
> > behaviour in virt-manager either. I tried:
> > 
> > 1. Ungrab kbd
> > 2. Hit Ctrl+q (nothing happened)
> 
> It's ctrl+shift+q,

That's for terminal.

> and you need to press ctrl+alt.

Yeah, I did, that is in fact Step#1 just above this step.

From these two alone, I'm fairly sure you are talking about the opposite here: Getting the system keys to guest. I'm expecting those shortcuts to work in virt-manager UI rather than inside the guest. That's why every other step is to ungrab the keyboard.

> > 3. Ungrab kbd again
> > 4. Hit Ctrl+w (nothing happened)
> > 5. Ungrab kbd again
> > 6. Hit Ctrl+w (nothing happened)
> 
> what's ctrl+w?

See File menu entry in virt-manager.

> > 9. Ungrab kbd again
> > 10. Tab to switch focus (focus remained on display and got a kbd bell from
> > terminal inside the guest demonstrating that key was received by guest)
> 
> there is no accelerator or handling of Tab or focus management in
> virt-viewer.

Of course not, Gtk+ will handle it if spice-gtk doesn't take the keys to the guest.

(In reply to Christophe Fergeau from comment #28)
> (In reply to Zeeshan Ali from comment #27)
> > Is it possible that none
> > of you cared to read the chat? In which case we were all being lazy, except
> > for Christophe. :)
> 
> I did not read the chat, and agree with others that it's bad from, and that
> the usual steps to reproduce/expected result/observed result would have made
> everything much clearer from the start.

Well keeping in mind that after all the explanation the followed for me and you, elmarco is still confused, and that my explanation would have simply been restating the first few sentences from the chat log, I'm not sure how much that would have helped. But yeah, I'll keep in mind in future.

(In reply to Zeeshan Ali from comment #30)
> (In reply to Marc-Andre Lureau from comment #29)
> > (In reply to Zeeshan Ali from comment #27)
> > > * What I'm asking for is keyboard-grab=false to work as expected. i-e No key
> > > events sucked by spice display when keyboard in ungrabbed even if widget is
> > > in focus. No, this is not a new state I'm asking for. It's what
> > > keyboard-unpgrab is meant for and it partially works (for system keys).
> > 
> > keyboard-ungrab is generally for system grab (nothing else by default) 
> 
> Currently that might be but I presented arguments of why it should be for
> all keys, above.
>  
> > > Now, as for it working in virt-viewer as expected, I do not see the expected
> > > behaviour in virt-manager either. I tried:
> > > 
> > > 1. Ungrab kbd
> > > 2. Hit Ctrl+q (nothing happened)
> > 
> > It's ctrl+shift+q,
> 
> That's for terminal.

and virt-viewer too

> 
> From these two alone, I'm fairly sure you are talking about the opposite
> here: Getting the system keys to guest. I'm expecting those shortcuts to
> work in virt-manager UI rather than inside the guest. That's why every other
> step is to ungrab the keyboard.

virt-manager doesn't have a good accelerator handling like virt-viewer.

> > > 3. Ungrab kbd again
> > > 4. Hit Ctrl+w (nothing happened)
> > > 5. Ungrab kbd again
> > > 6. Hit Ctrl+w (nothing happened)
> > 
> > what's ctrl+w?
> 
> See File menu entry in virt-manager.

we are talking about virt-viewer, it's the spice client of reference.

> 
> > > 9. Ungrab kbd again
> > > 10. Tab to switch focus (focus remained on display and got a kbd bell from
> > > terminal inside the guest demonstrating that key was received by guest)
> > 
> > there is no accelerator or handling of Tab or focus management in
> > virt-viewer.
> 
> Of course not, Gtk+ will handle it if spice-gtk doesn't take the keys to the
> guest.

No, it depends on widget input handling, see other focus handling of text/vte widget etc

Created attachment 120453 [details] [review]
widget: Ignore all key events after kbd ungrab

For one thing this completely breaks regrabbing the keyboard after first
ungrab but this is only for demonstrating what I expect to happen to all
key events (except for keboard grab keys of course) after I ungrab the
keyboard.

FWIW, I asked our UI designer Jakub Steiner if he agrees that all key events should go to Boxes UI rather than guest when kbd is ungrabbed explicitly and he said:

"Yes. Always prefer deterministic behavior even if it means an extra step to go through. Complex context switching isn't something we're good at. We can train to go through a predictable number of steps."

I think Marc-Andre mentioned it and made it clear. When you press the ungrab combo the keys does not go to the guest, they go to the app which has the focus. If you want to stop receiving the keys, just use the disable inputs property [0], as Marc-Andre said in the comment 4.

[0] http://www.spice-space.org/docs/spice-gtk/SpiceDisplay.html#SpiceDisplay--disable-inputs

(In reply to Pavel Grunt from comment #35)
> I think Marc-Andre mentioned it and made it clear. When you press the ungrab
> combo the keys does not go to the guest, they go to the app which has the
> focus.

Yes he did but I also pointed out that this rule is not so set in stone. Spice-gtk is a bit special:

1. You normally want *all* keyboard events to go to guest. If you compare it to 99% of widgets out there, they don't eat all keyboard events even if they are focused.

2. SpiceGtk already has this concept of keyboard-ungrab and I don't know of any gtk+ widget (except for vnc which is the same case) that has this concept. I'm not asking for a new state but rather extending the idea of this keyboard-ungrab to include all keys, as users would expect it to be, not just system keys.

Since users will be expecting that in all UIs, I strongly recommend this be solved by spice-gtk, rather than be done separately in every app that uses spice-gtk.

> If you want to stop receiving the keys, just use the disable inputs
> property [0], as Marc-Andre said in the comment 4.

That also disables mouse input and that's not at all what I want.

I looked into implementing it in Boxes yesterday and it's doable by switching focus to event_box that contains the SpiceGtk widget on keyboard ungrab and undoing that on receiving ungrab keys so it's not really a matter of "if Boxes can do it" but rather "Whether Boxes should do it".

(In reply to Zeeshan Ali from comment #36)
> (In reply to Pavel Grunt from comment #35)
> > I think Marc-Andre mentioned it and made it clear. When you press the ungrab
> > combo the keys does not go to the guest, they go to the app which has the
> > focus.
> 
> Yes he did but I also pointed out that this rule is not so set in stone.
> Spice-gtk is a bit special:
> 
> 1. You normally want *all* keyboard events to go to guest. If you compare it
> to 99% of widgets out there, they don't eat all keyboard events even if they
> are focused.

99% is a bit over-estimated, all input widget allowing you to type is not 1%...

> 2. SpiceGtk already has this concept of keyboard-ungrab and I don't know of
> any gtk+ widget (except for vnc which is the same case) that has this
> concept. I'm not asking for a new state but rather extending the idea of
> this keyboard-ungrab to include all keys, as users would expect it to be,
> not just system keys.
> 
> Since users will be expecting that in all UIs, I strongly recommend this be
> solved by spice-gtk, rather than be done separately in every app that uses
> spice-gtk.

Imho it's tricky to change spice-gtk keyboard behaviour at this point without breaking something, but perhaps something clever could be done, but it needs careful thinking and testing. I would rather like to see that behaviour adopted by a few apps before burring it in spice-gtk default behavour or API.

> > If you want to stop receiving the keys, just use the disable inputs
> > property [0], as Marc-Andre said in the comment 4.
> 
> That also disables mouse input and that's not at all what I want.

That's really broken to me. Having mouse input but no keyboard, I would immediately wonder what is wrong with the VM and how to solve it.

> I looked into implementing it in Boxes yesterday and it's doable by
> switching focus to event_box that contains the SpiceGtk widget on keyboard
> ungrab and undoing that on receiving ungrab keys so it's not really a matter
> of "if Boxes can do it" but rather "Whether Boxes should do it".

(In reply to Marc-Andre Lureau from comment #37)
> (In reply to Zeeshan Ali from comment #36)
> > (In reply to Pavel Grunt from comment #35)
> > > I think Marc-Andre mentioned it and made it clear. When you press the ungrab
> > > combo the keys does not go to the guest, they go to the app which has the
> > > focus.
> > 
> > Yes he did but I also pointed out that this rule is not so set in stone.
> > Spice-gtk is a bit special:
> > 
> > 1. You normally want *all* keyboard events to go to guest. If you compare it
> > to 99% of widgets out there, they don't eat all keyboard events even if they
> > are focused.
> 
> 99% is a bit over-estimated, all input widget allowing you to type is not
> 1%...
> 
> > 2. SpiceGtk already has this concept of keyboard-ungrab and I don't know of
> > any gtk+ widget (except for vnc which is the same case) that has this
> > concept. I'm not asking for a new state but rather extending the idea of
> > this keyboard-ungrab to include all keys, as users would expect it to be,
> > not just system keys.
> > 
> > Since users will be expecting that in all UIs, I strongly recommend this be
> > solved by spice-gtk, rather than be done separately in every app that uses
> > spice-gtk.
> 
> Imho it's tricky to change spice-gtk keyboard behaviour at this point
> without breaking something, but perhaps something clever could be done, but
> it needs careful thinking and testing. I would rather like to see that
> behaviour adopted by a few apps before burring it in spice-gtk default
> behavour or API.

Sure, it could be a behaviour explicitly requested by apps for now. My advice would be a simple boolean property that changes the "keyboard ungrab" to include all keys but I'm open to other API suggestions. I offer Boxes as the first Guinea pig for that.

> > > If you want to stop receiving the keys, just use the disable inputs
> > > property [0], as Marc-Andre said in the comment 4.
> > 
> > That also disables mouse input and that's not at all what I want.
> 
> That's really broken to me. Having mouse input but no keyboard, I would
> immediately wonder what is wrong with the VM and how to solve it.

Yeah, I realized that later. However, as I said on IRC, that doesn't help me since my event_box can't receive key events unless focus is switched to it.

So what's the verdict on my suggestion? An even simpler way that I can make use of in Boxes for now would be to add a function that let's app grab the keyboard.

(In reply to Zeeshan Ali from comment #39)
> So what's the verdict on my suggestion? An even simpler way that I can make
> use of in Boxes for now would be to add a function that let's app grab the
> keyboard.

Actually nm about the last request. Seems keyboard is grabbed automatically if display widget get's refocused. Although it seems "keyboard-grabbed" signal is not emitted for this event.

(In reply to Zeeshan Ali from comment #40)
> (In reply to Zeeshan Ali from comment #39)
> > So what's the verdict on my suggestion? An even simpler way that I can make
> > use of in Boxes for now would be to add a function that let's app grab the
> > keyboard.
> 
> Actually nm about the last request. Seems keyboard is grabbed automatically
> if display widget get's refocused. 

Sorry to keep going back & forth about this but on further testing, I realized that keyboard is not (re-)grabbed on focus-in event so I really would need an API from spice-gtk even if I handle this in Boxes.

(In reply to Zeeshan Ali from comment #41)
> Sorry to keep going back & forth about this but on further testing, I
> realized that keyboard is not (re-)grabbed on focus-in event so I really
> would need an API from spice-gtk even if I handle this in Boxes.

Or a bug fix. Do you have a wip branch to test your behaviour & issue?

FWIW, I briefly looked at virt-viewer code on how accelerators work in there and at least to me the code looks like a hack cause it modifies some gtk settings and according to the docs, apps aren't normally supposed to do that:

"Applications can override system-wide settings by setting the property of the GtkSettings object with g_object_set(). This should be restricted to special cases though; GtkSettings are not meant as an application configuration facility."

https://developer.gnome.org/gtk3/stable/GtkSettings.html

(In reply to Marc-Andre Lureau from comment #42)
> (In reply to Zeeshan Ali from comment #41)
> > Sorry to keep going back & forth about this but on further testing, I
> > realized that keyboard is not (re-)grabbed on focus-in event so I really
> > would need an API from spice-gtk even if I handle this in Boxes.
> 
> Or a bug fix. Do you have a wip branch to test your behaviour & issue?

I do, it's in quite a bit of flux though because of me trying out different things. I just pushed it up at wip/ungrab-focus2.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/spice/spice-gtk/issues/8.