> - 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 Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/36812 Title: Keyboard layout change on hotkeys press instead of release and do not work well with shortcuts To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-control-center/+bug/36812/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
