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
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
Similarly, shifting group with Shift+Right Alt (where Shift is pressed
first):
key RALT {
repeat= No,
type= TWO_LEVEL,
symbols[Group1]= [ Alt_R, Meta_R ],
actions[Group1]= [ SetMods(modifiers=Mod1),
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,
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.
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
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
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
(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
meaning of
9 matches
Mail list logo
