Don't strip XKB grp
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| gnome-settings-daemon (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
| unity-settings-daemon (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
unity-settings-
if (n_sources < 2 || g_strcmp0 (g_getenv ("XDG_CURRENT_
The original upstream source code is:
if (n_sources < 2)
That causes a problem: we're no longer able to type e.g. Greek in TuxPaint, because TuxPaint grabs the keyboard, and u-s-d then doesn't see the layout switching shortcut.
But: if we do revert only that line of the source code to what's in upstream, then we get another problem: that the XKB-defined layout switching shortcut (e.g. Alt+Shift) doesn't update the keyboard indicator in the panel, only the GNOME-defined shortcut (e.g. Win+Space) does.
To solve this, I think u-s-d needs to handle ISO_Next_Group. I don't know if that part exists upstream, but I do know that it works fine in Fedora 20.
After solving this bug, a tiny issue will remain: that Alt+Shift inside keyboard-grabbing applications won't update the keyboard indicator. Upstream GNOME doesn't want patches for that and may try to solve it in SDL, but the other 2 issues described above ^ are Ubuntu-specific.
| Alkis Georgopoulos (alkisg) wrote | #1 |
| tags: | added: patch |
| William Hua (attente) wrote | #2 |
| affects: | unity-settings-daemon → unity-settings-daemon (Ubuntu) |
Thanks Alkis, I don't know how Fedora is doing it, but under Ubuntu GNOME, this doesn't work for us. Having the grp option is causing problems because when ISO_Next_Group is pressed, g-s-d first handles it by setting the layout and locking the first group, then xkb handles it by switching to the second group, which is simply not correct.
We need some changes in Compiz which I'm blocked on because XKeyEvents work by keycode and ISO_Next_Group is a keysym. So this is not too easy either...