Created attachment 32545 [details] [review] Rename us(dvorak-intl) to more logical us(dvorak-alt-intl) The Dvorak variant of the us map lacks a dead key mode. It is not very practical working with both Dvorak keyboards and keyboards such as the TypeMatrix 2030 which can swap the keys in hardware, to end up with different mappings, and different behaviors depending on whether us(dvorak-intl) is used, or us(intl) with hardware key swapping. Additionaly, there is no option to have a dead keys based international dvorak natively. The following patches introduce 1) a change in nomenclature as variant dvorak-intl becomes dvorak-alt-intl, which is more logical in comparison with, say, variants intl and alt-intl (this may be problematic for system upgrades but, IMO, better on the long run), 2) a new dvorak-intl with dead keys, which is a replica of intl with keycodes swapped, 3) a fix so the above changes do not break the UK dvorak.
Created attachment 32546 [details] [review] New US international Dvorak variant with dead keys
Created attachment 32547 [details] [review] Adapt the uk(dvorak) variant so its not broken by the above patches
I am not really sure about breaking the compatibility. How many key mappings are affected? Also, would it be possible to derive the second variant on the first one, using "include" directive.
Only one key mapping is broken: the old us(dvorak-intl) is renamed to us(dvorak-alt-intl). The newly introduced mapping reuses the name us(dvorak-intl). Both of them include the original us(dvorak) variant and only redefine xeys that have more symbols attached to them. Unfortunately, apart from both being Dvark, the repartitons of symbols is quite different and the amount of changes would not justify one including the other. The justification for this compatibility break is to be more logical in naming the Dvorak variants, using the same scheme as for the QWERTY us variants. This will not be transparent for users upgrading to this new version of the definition (though this could be done at the distro level), as they will have to either adapt their configuration or try out and decide to change to this new mapping. However, this is a one-off issue which doesn't create reccuring problems over an extended period of time. As this is a move towards a more logical naming (IMO), I think this price is low enough to be paid.
Created attachment 33306 [details] [review] Correct a mistake in the previous patchset where key AD11 (?, /) was missing the international symbols (¿ and ̉)
Usually, I do not like breaking compatibility. But in this particular case that sounds logical, with small level of visibility(I guess). Committed, thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.