Ubuntu GNOME

Bug #1218322
Comment #46

Comment 46 for bug 1218322

Revision history for this message

Egmont Koblinger (egmont-gmail) wrote on 2013-10-16:

#46

Hi William,

I've installed your updates, and logged out and in just to be sure. Here's what I get (continuing comment 35):

The order in which I release the keys still matters. This makes it pretty much unusable for me, since the combo I'm used to (rolling my hand from right to left: press Alt, press Shift, release Alt release Shift) does not work anymore. The behavior of key combos is always to act on keypress, e.g. Ctrl+Space should switch the layout as soon as I press the space (and update the indicator too), and the order in which I release should not matter. Same goes for modifier-only key combos. The order in which the modifiers are pressed shouldn't matter either.

As far as I know, the old version relied on XKB groups, i.e. X Window was configured to execute the keymap change internally, independently of the desktop environment. The applet just provided a feedback of X's internal state, and a method to change that. I really don't know anything about the new system, but I seem to get a weird (and problematic) behavior of these two methods conflicting. As I've mentioned, I've upgraded from previous versions so I probably have tons of leftover of my old preference everywhere (both personal gnome config, and system-wide X config). (My old config is: having us and hu layouts, and Alt+Shift as toggle. Neither the press order, nor the release order of these two keys mattered previously.)

When I hit Alt+Shift as the new hotkey in Text Entry Settings, I get "Shift+Alt+Next Group" displayed as the hotkey. This clearly shows that the Alt+Shift toggle of XKB groups is still in effect. If I choose English in the menu, no shortcut changes layout. If I choose Hungarian, the Alt+Shift combo (in any of the 4 ways of pressing/releases) switches layout without updating the indicator. Exactly as when I specify a different shortcut in Gnome which I don't press at all. This is a clear indication that an Xkb group change happens, unaware to gnome / indicator-kbd.

I executed >> setxkbmap us,hu -option '' << from the terminal to clear the XKB switching shortcut. Now, if I specify the desired shortcut in Text Entry, I see "Alt+Shift L" which looks way more promising. From this moment, only 1 of the 4 possible press/release orders work: press Alt, pres Shift, release Shift, release Alt. (Again: such behavior is unusable for me.) When pressing this combo, the layout changes and it's reflected in the indicator. It's a clear sign that this event was handled by Gnome, and not Xkb. But: when pressing this combo for the first time, everything gets reverted to the previous behavior. Alt+Shift is resurrected as an Xkb group switcher (any 4 orders toggle the layout, but only if the indicator shows Hu, not when on En; and the modification is not reflected. Specifying Alt+Shift as the shortcut again displays "Shift+Alt+Next Group".) I'm not sure where the old Xkb setting is resurrected from.

Summary:

- Previously Gnome relied on Xkb groups, something I was familiar with. (About 8-10 years ago it was finally a great solution, compared to executing xmodmap all the time. It was nice to see how X implemented support, and Gnome/Kde migrated to using this feature. Everything worked fine for me, and I could even switch desktop environment / window managers without having to configure anything. Now it's all broken again.) Now apparently we have some brand new method, I don't know anything about its technical details. I'm not sure what was the reason for such an infrastructure change.

- As most likely users will prefer to keep (or re-specify) the same switcher, it's very important that the old way of setting it (both system-wide (if any) and personal gnome config (if any)) is cleaned up during the upgrade. This does not happen now. The old and new methods of switching layout conflict in terrible ways, let alone the minor detail that they want to (and of course fail to) grab the same hotkey. It is still horribly broken.

- The release order of keys really must not matter.

Hi William,

I've installed your updates, and logged out and in just to be sure.  Here's what I get (continuing comment 35):

The order in which I release the keys still matters.  This makes it pretty much unusable for me, since the combo I'm used to (rolling my hand from right to left: press Alt, press Shift, release Alt release Shift) does not work anymore.  The behavior of key combos is always to act on keypress, e.g. Ctrl+Space should switch the layout as soon as I press the space (and update the indicator too), and the order in which I release should not matter.  Same goes for modifier-only key combos.  The order in which the modifiers are pressed shouldn't matter either.

As far as I know, the old version relied on XKB groups, i.e. X Window was configured to execute the keymap change internally, independently of the desktop environment.  The applet just provided a feedback of X's internal state, and a method to change that.  I really don't know anything about the new system, but I seem to get a weird (and problematic) behavior of these two methods conflicting.  As I've mentioned, I've upgraded from previous versions so I probably have tons of leftover of my old preference everywhere (both personal gnome config, and system-wide X config).  (My old config is: having us and hu layouts, and Alt+Shift as toggle. Neither the press order, nor the release order of these two keys mattered previously.)

When I hit Alt+Shift as the new hotkey in Text Entry Settings, I get "Shift+Alt+Next Group" displayed as the hotkey.  This clearly shows that the Alt+Shift toggle of XKB groups is still in effect.  If I choose English in the menu, no shortcut changes layout.  If I choose Hungarian, the Alt+Shift combo (in any of the 4 ways of pressing/releases) switches layout without updating the indicator.  Exactly as when I specify a different shortcut in Gnome which I don't press at all.  This is a clear indication that an Xkb group change happens, unaware to gnome / indicator-kbd.

I executed >> setxkbmap us,hu -option '' << from the terminal to clear the XKB switching shortcut.  Now, if I specify the desired shortcut in Text Entry, I see "Alt+Shift L" which looks way more promising.  From this moment, only 1 of the 4 possible press/release orders work: press Alt, pres Shift, release Shift, release Alt.  (Again: such behavior is unusable for me.)  When pressing this combo, the layout changes and it's reflected in the indicator.  It's a clear sign that this event was handled by Gnome, and not Xkb.  But: when pressing this combo for the first time, everything gets reverted to the previous behavior.  Alt+Shift is resurrected as an Xkb group switcher (any 4 orders toggle the layout, but only if the indicator shows Hu, not when on En; and the modification is not reflected.  Specifying Alt+Shift as the shortcut again displays "Shift+Alt+Next Group".)  I'm not sure where the old Xkb setting is resurrected from.

Summary:

- Previously Gnome relied on Xkb groups, something I was familiar with.  (About 8-10 years ago it was finally a great solution, compared to executing xmodmap all the time.  It was nice to see how X implemented support, and Gnome/Kde migrated to using this feature.  Everything worked fine for me, and I could even switch desktop environment / window managers without having to configure anything.  Now it's all broken again.)  Now apparently we have some brand new method, I don't know anything about its technical details.  I'm not sure what was the reason for such an infrastructure change.

- As most likely users will prefer to keep (or re-specify) the same switcher, it's very important that the old way of setting it (both system-wide (if any) and personal gnome config (if any)) is cleaned up during the upgrade.  This does not happen now.  The old and new methods of switching layout conflict in terrible ways, let alone the minor detail that they want to (and of course fail to) grab the same hotkey.  It is still horribly broken.

- The release order of keys really must not matter.