This reminds me of bug #45008. Just here, LOCAL_EIGHT_LEVEL does not
preserve Control. Adding preserve[Control]= Control into
LOCAL_EIGHT_LEVEL might fix the issue, an as it is not used elsewhere,
it actually might be acceptable [but it also means that
LOCAL_EIGHT_LEVEL in really a waste, given t
This reminds me of bug #45008. Just here, LOCAL_EIGHT_LEVEL does not
preserve Control. Adding preserve[Control]= Control into
LOCAL_EIGHT_LEVEL might fix the issue, an as it is not used elsewhere,
it actually might be acceptable [but it also means that
LOCAL_EIGHT_LEVEL in really a waste, given t
Created attachment 69198
LockMods can lock another group
This patch follows a different route: It extends modifier locking,
rather than changing how group lock works. Extending has the advantage
that the previous behaviour is maintained, and the patch does not
violate the X Keyboard Protocol Speci
Created attachment 69213
LockMods can lock another group
My previous patch does not properly account for absolute group
specification. The revised patch corrects this.
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to the bug report.
https://bugs.
> Is this mean your patch won't work when Alt (or Ctrl) is pressed before
> Shift?
It does not mean that. I just restricted to three examples. There is
no problem to rewrite all options that xkeyboard-config offers to switch
groups to take advantage of the patch.
> AFAIK most people press Ctrl,
Similarly, shifting group with Shift+Right Alt (where Shift is pressed
first):
key {
repeat= No,
type= "TWO_LEVEL",
symbols[Group1]= [ Alt_R, Meta_R ],
actions[Group1]= [ SetMods(modifiers=Mod1),
Private(type=3,data[
> 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
p
I believe the most serious objection with this request is that it
violates the XKB specification (see the description of SA_LockGroup in
section 6.3 of "The X Keyboard Extension: Protocol Specification").
In the same specification, in section 4.0 of appendix D ("Protocol
Encoding"), we see in the
(In reply to comment #107)
> A Windows-only compose key program uses the "ctrl" key as the compose key.
> This is apparently impossible to do in X input methods because you can only
> bind actions to the press of "ctrl".
Of course this is possible. Compose is unrelated to actions in the XKB
meani
9 matches
Mail list logo
