Comment 175 for bug 36812

> Your proposal is very correct, no doubt. Does it mean that once your
> proposal is implemented all 3rd-party keyboard switchers (like those in
> Gnome and KDE) would have to be updated to make use of this new possibility?

As far as I understand, KDE and Gnome all use xkeyboard-config, and just provide their own GUI. If this is understanding is correct, the changes to xkeyboard-config would be sufficient.

> Anyway, as i see it, there are two ways to go:
> 1) The long way - making things right and according to specification. This
> would take from very long to forever (this is the way we've been going for
> the last 8 years with this bug report).

Assuming the existing patch is correct, adding the additional check for the flag is just a few lines. The changes to xkeyboard-config would be fairly simple. Assuming we grab bit 3 for the new flag, in xkeyboard-config/compat/iso9995, change the current definition:

  interpret ISO_Next_Group {
      useModMapMods= level1;
      virtualModifier= AltGr;
      action= LockGroup(group=+1);
  }

to

  interpret ISO_Next_Group {
      useModMapMods= level1;
      virtualModifier= AltGr;
      action= Private(type=6, data[0]=16, data[1]=1);
  }

(untested, of course), and similarly for ISO_Prev_Group, ISO_First_Group, and ISO_Last_Group. I do not know wether the action bound to keysyms is standardised; even if it is not, it might be a good idea to make the above redefinition conditional.

> 2) Take a short way - let the common sense win over specification and make
> everybody happy.

Believe it or not, I would be unhappy when the specification would be broken. Also remember that the attitudes in this discussion are not necessarily representative of all X users, as the users satisfied with the current behaviour do not have any reason to even know about this discussion.