[Bug 221112]
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 that other types had to be removed because some programs had problems with too many types]. I do not have rythmbox, so I cannot test. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to rhythmbox in 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 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 36812]
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 Specification. Extending modifier
locking rather than group locking has the advantage that we do not need
the Kludge of the other patch, as we can pass the modifiers that we
want to set, rather then relying on heuristics.
The disadvantage over the existing patch is that we must change the
keymap.
Here are three examples. The left alt key is to switch to the next
layout when it is pressed and released before any other key is pressed.
key LALT {
repeat= No,
type= TWO_LEVEL,
symbols[Group1]= [ Alt_L, Meta_L ],
actions[Group1]= [
Private(type=3,data[0]=1,data[1]=8,data[2]=8,data[3]=0,data[4]=0,data[5]=0,data[6]=1),
Private(type=3,data[0]=1,data[1]=8,data[2]=8,data[3]=0,data[4]=0,data[5]=0,data[6]=1)
]
};
Similarly, shifting group with Shift+Right Alt (where Shift is pressed
first):
--
You received this bug notification because you are a member of Ubuntu
Desktop 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
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 36812]
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, then Shift, then either release them (to
switch layout) or press A-Z when they need Ctrl-Shift-something hotkey.
In this case, one needs to remap the shift key. For the left shift key:
key LFSH {
repeat= No,
type[Group1]=PC_CONTROL_LEVEL2,
symbols[Group1]= [ Shift_L, Shift_L ],
actions[Group1]= [ SetMods(modifiers=Shift),
Private(type=3,data[0]=1,data[1]=1,data[2]=1,data[3]=0,data[4]=0,data[5]=0,data[6]=1)
]
};
For the right shift key it works similarly. If combined with the third
example above, it will make the order of Shift and Control irrelevant.
--
You received this bug notification because you are a member of Ubuntu
Desktop 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
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 36812]
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),
Private(type=3,data[0]=1,data[1]=8,data[2]=8,data[3]=0,data[4]=0,data[5]=0,data[6]=1)
]
};
Shifting group with Shift+Left Control:
key LCTL {
repeat= No,
type= TWO_LEVEL,
symbols[Group1]= [ Control_L, Control_L ],
actions[Group1]= [ SetMods(modifiers=Control),
Private(type=3,data[0]=1,data[1]=4,data[2]=4,data[3]=0,data[4]=0,data[5]=0,data[6]=1)
]
};
--
You received this bug notification because you are a member of Ubuntu
Desktop 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
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 36812]
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 Desktop 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 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 36812]
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 description of SA_LockGroup that there are still 5 unused bits in the flags field. My proposal in to use one of these bits decide whether to lock groups on press or release. By default (bit is zero), lock groups on press as the protocol specification demands. If the flag is one, lock groups on release. So by default, we would conform to the specification, and add the alternative behaviour as a new possibility beyond the specification. There are some usage implications. One must use 'Private' do create actions with the new flag set (until xkbcomp is updated as well), and one needs support in xkeyboard-config to make the new feature usable for non-XKB-hackers. -- You received this bug notification because you are a member of Ubuntu Desktop 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 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 36812]
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
provide their own GUI. If this is understanding is correct, the changes
to xkeyboard-config would be sufficient.
Anyway, as i see it, there are two ways to go:
1) The long way - making things right and according to specification. This
would take from very long to forever (this is the way we've been going for
the last 8 years with this bug report).
Assuming the existing patch is correct, adding the additional check for
the flag is just a few lines. The changes to xkeyboard-config would be
fairly simple. Assuming we grab bit 3 for the new flag, in xkeyboard-
config/compat/iso9995, change the current definition:
interpret ISO_Next_Group {
useModMapMods= level1;
virtualModifier= AltGr;
action= LockGroup(group=+1);
}
to
interpret ISO_Next_Group {
useModMapMods= level1;
virtualModifier= AltGr;
action= Private(type=6, data[0]=16, data[1]=1);
}
(untested, of course), and similarly for ISO_Prev_Group,
ISO_First_Group, and ISO_Last_Group. I do not know wether the action
bound to keysyms is standardised; even if it is not, it might be a good
idea to make the above redefinition conditional.
2) Take a short way - let the common sense win over specification and make
everybody happy.
Believe it or not, I would be unhappy when the specification would be
broken. Also remember that the attitudes in this discussion are not
necessarily representative of all X users, as the users satisfied with
the current behaviour do not have any reason to even know about this
discussion.
--
You received this bug notification because you are a member of Ubuntu
Desktop 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
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 36812]
(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 the term. It is not only possible, it is even implemented in the XIM compose code. You can put Control_Lae : ae and similar stuff in your .XCompose, and your left control key acts as a Compose key. But you need the latest libX11 for this. -- You received this bug notification because you are a member of Ubuntu Desktop 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 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
