(In reply to comment #45)
> (In reply to comment #44)
> > Until a solution is to be found, could 518c769d be reverted for now?
> > Breaking the very standard behavior of right control
>
> It does not break the very standard behavior of right control any more than
> altrgr breaks the very standard behavior of right alt
For me it does. My keyboard has an "Alt Gr" label on the AltR key, so
it indeed is expected to behave differently from Alt_L, but my ControlR
key is labeled as "Ctrl", just like the ControlL key. And all other
keyboards and OSes I ever used did handle ControlR the same as ControlL,
as far as I was concerned as a user.
Also, I find it more generically problematic to change the behavior of a
common key on a widely used keymap. For example the change annoyed me
for about a month before I took the time to debug this and edit my
keymap -- and I can't imagine what a lambda user could do but learn to
deal with it.
Also, what is Level5 used for? IIUC, currently nothing but short-nbsp
(or at least that I can find, which is practically the same from a user
POV), turning Ctrl_R into a virtually useless key.
So, what can we do?
First, please note, for what is worth, that both Rhythmbox and Totem, which
were cited as the applications having a problem with the previous state of
things, are not affected anymore. Rhythmbox don't use Control+Space as a
shortcut anymore, and Totem seem to react to any space keysym, no matter the
modifiers.
So, unless there actually are other applications using Control+Space and
suffering of the issue (Code::Blocks?), the problem does not even exist anymore.
Also, maybe I just don't know how one is supposed to process the events, but
those bugs look like an application or toolkit issue to me, is it?
Then, practical changes. Before the change, Space behaved like this:
Shift* | Control* | Level3 || keysym | XLookupString
---------------------------||--------------------------
| | || 0x20 | 20
X | | || 0x20 | 20
| X | || 0x20 | 20
| | X || 0x20 | 20
X | X | || 0x100202f | e2 80 af
X | | X || 0xa0 | c2 a0
| X | X || NoSymbol |
X | X | X || NoSymbol |
And now we have:
Shift* | ControlL | Level3 | Level5 || keysym | XLookupString
------------------------------------||---------------------------------
| | | || 0x20 | 20
X | | | || 0x20 | 20
| X | | || 0x20 | 00
| | X | || 0x20 | 20
| | | X || 0x20 | 20
X | X | | || 0x20 | 00
X | | X | || 0xa0 | c2 a0
X | | | X || 0x100202f | e2 80 af
| X | X | || 0x20 | 00
| X | | X || 0x20 | 00
| | X | X || NoSymbol |
X | X | X | || 0xa0 | (empty)
X | X | | X || | (no event on Xev???)
X | | X | X || NoSymbol |
X | X | X | X || | (no event on Xev???)
So. IIUC, the problem is having naked Space emit the same XLookupString that
Control+Space, right? The new behavior is emitting lookup string "00" with
modifier Control, so I guess this is the fix.
So, what about simply changing the original map to have a different
lookup string on Control? Like this:
Shift* | Control* | Level3 || keysym | XLookupString
---------------------------||--------------------------
| | || 0x20 | 20
X | | || 0x20 | 20
| X | || 0x20 | 00
| | X || 0x20 | 20
X | X | || 0x100202f | e2 80 af
X | | X || 0xa0 | c2 a0
| X | X || NoSymbol |
X | X | X || NoSymbol |
Or, if we don't want to have anything useful using Control, what about moving
0x100202f to Level3? Like this:
Shift* | Control* | Level3 || keysym | XLookupString
---------------------------||--------------------------
| | || 0x20 | 20
X | | || 0x20 | 20
| X | || 0x20 | 00
| | X || 0x100202f | e2 80 af
X | X | || 0x20 | 00
X | | X || 0xa0 | c2 a0
| X | X || NoSymbol |
X | X | X || NoSymbol |
Alternatively, the mapping of ControlR to Level5 could be an option (or a
slightly different variant, whatever's better).
Anything that could prevent me from manually editing my map to have ControlR
again would be totally great.
--
You received this bug notification because you are a member of Desktop
Packages, 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
Status in libgnomekbd:
Confirmed
Status in Listen, a Music player and management:
Confirmed
Status in Quod Libet is a GTK+-based audio player written in Python.:
Unknown
Status in The Rhythmbox Music Management Application:
Confirmed
Status in SciTE - A free source code editor for Win32 and X:
New
Status in central project for keyboard configuration:
Confirmed
Status in “quodlibet” package in Ubuntu:
Invalid
Status in “rhythmbox” package in Ubuntu:
Fix Released
Status in “xkeyboard-config” package in Ubuntu:
Fix Released
Status in “xkeyboard-config” source package in Precise:
Triaged
Bug description:
[Impact]
In the fr(oss) keymap, both space and Ctrl + space return the same
XLookupString, which prevents space from being used in some applications.
This had been fixed in lucid and maverick, but the patch appears to
have been misplaced during the (rather major) update from 1.8 to 2.1,
thus the reports of it regressing in comments #135 and #141, as well
as dupe bug #938671.
[Development Fix]
Patch 128_fix_oss_ctrl_space_accelerator.patch fixed this problem in lucid
and maverick, but was dropped in natty when we updated to upstream
xkeyboard-config 2.1. However, the patch was also sent upstream and accepted
there. So for quantal a cherrypick of that commit was backported.
[Stable Fix]
Since currently quantal is shipping the same xkeyboard-config version as
precise, we can carry the same patch there as well.
[Test Case]
1. Set keyboard to fr(oss). (Note due to unrelated bug, you need to do this
in your /etc/defaults/keyboard config file.)
2. Start rhythmbox
3. Do a song search
4. Type in a search term that includes a space character
Broken Behavior: Space triggers the play/pause function in rhythmbox
Fixed Behavior: A space character is inserted
[Regression Potential]
The patch is one we carried in lucid and maverick (when rhythmbox was the
default music player IIRC), and has been upstream for a while. So I think it
is a safe change.
Actually, I'm surprised there have not been more complaints about it
lately. But during the interim we'd switched to banshee so perhaps
users didn't notice it.
[Original Report]
I tried to search for "The Do" in the search bar, but the space bar didn't
write a space. Instead, it played the currently selected song (space is the
shortcut for playing/pausing the song). I've just installed the last Hardy
release candidate.
ProblemType: Bug
Architecture: i386
Date: Wed Apr 23 19:30:12 2008
DistroRelease: Ubuntu 8.04
ExecutablePath: /usr/bin/rhythmbox
NonfreeKernelModules: nvidia
Package: rhythmbox 0.11.5-0ubuntu6
PackageArchitecture: i386
ProcEnviron:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
LANG=fr_FR.UTF-8
SHELL=/bin/bash
SourcePackage: rhythmbox
Uname: Linux 2.6.24-16-generic i686
To manage notifications about this bug go to:
https://bugs.launchpad.net/libgnomekbd/+bug/221112/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
