Launchpad has imported 19 comments from the remote bug at
https://bugzilla.gnome.org/show_bug.cgi?id=700316.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
On 2013-05-14T16:24:45+00:00 Federico Mena Quintero wrote:
(I'm not sure if gnome-settings-daemon is the right product for this
bug, but anyway.)
I have things so that pressing ShiftL+ShiftR together will change my
keyboard layout.
This works fine. However, when I press that key combination, the
current window appears to lose focus and regain it instantly. This is a
problem with buggy toolkits (cough) that do things like committing or
canceling text entries when they lose/gain focus. For example,
GtkTreeView will cancel editing, and Firefox will do funny things
depending on which web page has entry widgets in it.
This didn't seem to happen a few Gnome versions ago (maybe it was caused
by the switch to ibus?).
Here is the xev log for what it's worth. After the initial ShiftL
KeyPress, there is a FocusOut/FocusIn/KeymapNotify.
KeyPress event, serial 44, synthetic NO, window 0x481,
root 0xc1, subw 0x0, time 257173342, (412,453), root:(413,530),
state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
FocusOut event, serial 44, synthetic NO, window 0x481,
mode NotifyGrab, detail NotifyAncestor
FocusIn event, serial 44, synthetic NO, window 0x481,
mode NotifyUngrab, detail NotifyAncestor
KeymapNotify event, serial 44, synthetic NO, window 0x0,
keys: 2 0 0 0 0 0 4 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
MappingNotify event, serial 44, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 8, count 248
MappingNotify event, serial 44, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 8, count 248
MappingNotify event, serial 44, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 8, count 248
MappingNotify event, serial 44, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 8, count 248
MappingNotify event, serial 44, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 8, count 248
MappingNotify event, serial 44, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 8, count 248
MappingNotify event, serial 44, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 8, count 248
MappingNotify event, serial 44, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 8, count 248
KeyRelease event, serial 44, synthetic NO, window 0x481,
root 0xc1, subw 0x0, time 257173533, (412,453), root:(413,530),
state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/0
On 2013-05-14T16:28:38+00:00 Rui Matos wrote:
Well, yes because it's a shortcut like any other now which means we use
X passive grabs which causes FocusOut/In events indeed. I don't know
what to say other than fix the clients.
Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/1
On 2013-05-14T16:29:56+00:00 Bugzilla-x wrote:
(In reply to comment #1)
> Well, yes because it's a shortcut like any other now which means we use X
> passive grabs which causes FocusOut/In events indeed. I don't know what to say
> other than fix the clients.
Isn't that fixed already in GNOME 3.8?
Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/2
On 2013-05-14T16:32:47+00:00 Rui Matos wrote:
(In reply to comment #2)
> (In reply to comment #1)
> > Well, yes because it's a shortcut like any other now which means we use X
> > passive grabs which causes FocusOut/In events indeed. I don't know what to
> > say
> > other than fix the clients.
>
> Isn't that fixed already in GNOME 3.8?
No it can't be "fixed" unfortunately, it's how X grabs work.
Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/3
On 2013-10-26T05:48:07+00:00 Suor wrote:
Can confirm that.
And that should be fixed, it's useful for window or widget to do
something on focus loss and it's very common to type a message in
several languages.
Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/7
