[Bug 36812]
> - 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
[Bug 36812]
Created attachment 131147 Proposed extension of the XKB protocol. > Therefore, my proposal for you (or anyone else who is interested in changing > the behavior) is to provide a patch against the spec. That is a very good proposal. The patch formalises my proposal from comment #112. An implementation was posted it the following thread: https://lists.x.org/archives/xorg-devel/2012-November/034427.html -- 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
[Bug 36812]
(In reply to Zebediah Figura from comment #189) > Can anyone shed light, for the outside user, as to the current status of > this proposal? Thanks. No news since. Apart from the formal proposal, there are some old patches for its implementation: https://lists.x.org/archives/xorg-devel/2012-November/034427.html https://lists.x.org/archives/xorg-devel/2012-November/034430.html https://lists.x.org/archives/xorg-devel/2012-November/034429.html https://lists.x.org/archives/xorg-devel/2012-November/034431.html https://lists.x.org/archives/xorg-devel/2012-November/034428.html -- 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
[Bug 36812]
Allowing arbitrary sequences to decide which action to take would certainly be powerful, but quite some effort, also for specification (think about multiple matching sequences). In comment #117 I suggested an extension to the specification that is restricted to the enhancement request at hand. But even this change would need a protocol bump. This is where this proposal is stuck. -- 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
[Bug 1299829]
It seems that it has already been fixed (commit 4779e2745094ebe0c06364b4099d7067ae750d07) in response to this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=647433 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1299829 Title: keyboard for Bambara not usable : name in evdev.xml points to Malayalam. To manage notifications about this bug go to: https://bugs.launchpad.net/xkeyboard-config/+bug/1299829/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 221112]
Created attachment 98826 Make Level 5 choosers more easily available The patch makes existing options for Level 5 choosers more easily available by adding them to the rules. This is useful in its own right, irrespective of this bug. In context of this ongoing discussion, it would allow to change back to the old default, and allow users who prefer the current behaviour to use the options lv5:rctrl_switch and nbsp:level4n to get their preferred behaviour. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/221112 Title: Can't use space bar in search bar when using french alternative keyboard To manage notifications about this bug go to: https://bugs.launchpad.net/libgnomekbd/+bug/221112/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1013881]
Created attachment 98826 Make Level 5 choosers more easily available The patch makes existing options for Level 5 choosers more easily available by adding them to the rules. This is useful in its own right, irrespective of this bug. In context of this ongoing discussion, it would allow to change back to the old default, and allow users who prefer the current behaviour to use the options lv5:rctrl_switch and nbsp:level4n to get their preferred behaviour. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1013881 Title: Right-Ctrl key broken on French OSS keyboard To manage notifications about this bug go to: https://bugs.launchpad.net/xkeyboard-config/+bug/1013881/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
