> - Can you describe a bit how you imagine the changes to xkeyboard-config > would look with this approach? We would need changes wherever we want the new behaviour. I would prefer to create new options for group switching, rather than modifying existing options. Comments #117 and #118 show examples. Basically, I imagine we use explicit action specifications. However, unless as shown in the examples, with changes to xkbcomp, one could write 'LockMods' with an 'group' option, rather than using the cryptic 'Private' actions.
> - Do you think this can be done in a backwards compatible way? As far as > xkbcommon is concerned, I am only interested in this scenario: old library > (unaware of the new LockMods options) & new keymap (in textual form, > modified with the new flags). Certainly, an old library or application would get parse errors when it encountered the new options in textual form. If xkeyboard-config adds new options rather than modifying old ones, users could just keep using the old options until they upgraded the library/application. If the library/application parses only used stuff, that would circument transitional compatibility issues. For an old xkbcomp with a new xkeyboard-config, I believe that would work. As I far as remember, xkbcommon intentionally does not support 'Private'; otherwise, using it could help during the transition. > X has more compatibility concerns, Yes. Peter's main concern was that some tools might create binary forms of a layout where the two bytes that now get a meaning are not zero, but set to some random values (zero is fine, as it will have no effect in the new interpretation). His idea was to bump the protocol version, but that is beyond my capabilities, so I gave up at this point. Anyway, current xkbcomp puts the bytes to zero, so the combination of an old xkbcomp with new X-server would be no problem, ever without the precaution of a protocol version bump. > BTW: xkbcommon already supports noLock/noUnlock in LockMods (unlike xkbcomp), > based on your work[1]. So I hope the approach does not rely on these not > already working :) With my proposal, xkbcomp should be touched anyway, and this is just one of three occasions where I unsuccessfully tried to get noLock/noUnlock supported in xkbcomp. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg-server in Ubuntu. https://bugs.launchpad.net/bugs/36812 Title: Keyboard layout change on hotkeys press instead of release and do not work well with shortcuts Status in gnome-control-center: Unknown Status in X.Org X server: Confirmed Status in gnome-control-center package in Ubuntu: Invalid Status in xorg-server package in Ubuntu: Fix Released Bug description: This is a bug about shortcuts mapped to combinations which include each other. For example, if we have Ctrl+Shift (for keyboard layout) and Ctrl+Shift+N (to open a new terminal), then we are practically unable to use the second shortcut; this is what happens: Ctrl press (nothing happens) Shift press (keyboard layout change) N (a simple N appears, since a shortcut has already fired) The expected behavior is to fire shortcuts on the release (not on press) of the special keys (ctrl,shift,alt, etc) which is also how Windows behave. This is a serious problem for bilingual layouts, typically using Alt+Shift or Ctrl+Shift for keyboard layout change. For users being affected by this problem, the easiest solution for now is to add this PPA in your repositories: https://launchpad.net/~oded-geek/+archive/xorg-patches Practical summary of this bug for ubuntu developers (since reading 120 comments is impractical for most): This problem is a really old (since 2004) issue of the xkb part of xorg; the main discussion was made upstream in freedesktop-bugs #865. There has been a patch from Ilya Murav'jov for upstream (#55), and attached here (#61). Upstream xorg has refused to apply the patch, mainly because it "explicitly contradicts the (xkb) spec" (#84, #91). This patch has been reported to work for many people without any problems, and there is also a PPA by Oded Arbel (#95) where he maintains a patched version of the ubuntu xorg. The proper resolution of this bug would be to apply this patch to the upstream xorg, or at minimum to the official ubuntu xorg package. To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-control-center/+bug/36812/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
