> 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:
(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.
> 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 { Mods= level1; difier= AltGr; group=+ 1);
useModMap
virtualMo
action= LockGroup(
}
to
interpret ISO_Next_Group { Mods= level1; difier= AltGr;
useModMap
virtualMo
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.