SciTE - A free source code editor for Win32 and X

Can't use space bar in search bar when using french alternative keyboard

Reported by Creak on 2008-04-23
276
This bug affects 32 people
Affects Status Importance Assigned to Milestone
Listen
Undecided
Unassigned
QuodLibet
Unknown
Unknown
Rhythmbox
Confirmed
Medium
SciTE
New
Undecided
Unassigned
libgnomekbd
Confirmed
Medium
xkeyboard-config
Confirmed
Medium
quodlibet (Ubuntu)
Undecided
Unassigned
rhythmbox (Ubuntu)
High
Didier Roche
xkeyboard-config (Ubuntu)
High
Didier Roche
Precise
High
Unassigned

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

Creak (romain-failliot) wrote :

I cannot reproduce.

Space shouldn't be the default, for exactly this reason. The defaut (at least for me) is ctrl + space. Make sure you aren't holding down your ctrl key accidentally (or something heavy isn't sitting on it). You can check the current shortcut under the control menu.

Does this help anything?

Changed in rhythmbox:
status: New → Incomplete
Creak (romain-failliot) wrote :

Well i retried and it does all the same... The space bar works like a charm in the other aplications.
Could it be possible that the french translation changed the shortcut?

Ludovic Lebègue (llebegue) wrote :

Same problem here with the default install and language English as default. (But a French keyboard layout)
This makes it impossible to search any information containing a space.

Ludovic Lebègue (llebegue) wrote :

Tried with a USA layout for the keyboard. The problem is still there.

Changed in rhythmbox:
status: Incomplete → Confirmed

Can both of you attach your xorg.conf files, or at least the relevant sections containing your keyboard layout?

"cp /etc/X11/xorg.conf ~/ " will put a copy in your home folder for attachment.

Ludovic Lebègue (llebegue) wrote :

Here is my xorg.conf

Creak (romain-failliot) wrote :

Here is mine

Ronan Jouchet (ronj) wrote :

Can confirm this. I've filed 222654 then found this bug. I've marked 222654 as duplicate of this.
I attach my xorg.conf

I have another request, as I still cannot reproduce this bug. Can you attach your %gconf file for your keyboard?
Use the terminal command "cp ~/.gconf/desktop/gnome/peripherals/keyboard/kbd/%gconf.xml ~/key-gconf.txt"
and upload the file "key-gconf.txt" to launchpad

merci beaucoup!

I forgot to mention, the key-gconf.txt file will be located in your home directory after entering that terminal command.

Changed in rhythmbox:
assignee: nobody → patrick-kilgore
Ludovic Lebègue (llebegue) wrote :

Here is the gnome keyboard config.

Reproduced and forwarded upstream. You can track any progress there at http://bugzilla.gnome.org/show_bug.cgi?id=530123

Thanks for helping make Ubuntu better!

Changed in rhythmbox:
assignee: patrick-kilgore → nobody
blahnotblahblah (coufan) wrote :

I solved the problem by commenting on a line in /etc/X11/xorg.conf :
Option "XkbVariant" "oss"

Section "InputDevice"
        Identifier "Generic Keyboard"
        Driver "kbd"
        Option "CoreKeyboard"
        Option "XkbRules" "xorg"
        Option "XkbModel" "pc105"
        Option "XkbLayout" "fr"
# Option "XkbVariant" "oss"
EndSection

Then I made slim system\quit\disconnect
And since the problem disappeared in codeblocks
I am satisfied!!!

Changed in rhythmbox:
status: Unknown → New
Sika (sikamikaniboots) wrote :

I have the same problem with Quod Libet and CodeBlocks.
Xev tells me that "space" key is pressed, but in these apps, everything happens like if ctrl+space was stroke (play/pause in quod libet, completion in codeblocks).
My xorg.conf :

Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "CoreKeyboard"
 Option "XkbRules" "xorg"
 Option "XkbModel" "pc105"
 Option "XkbLayout" "fr"
 Option "XkbVariant" "oss"
 Option "XkbOptions" "lv3:ralt_switch"
EndSection

Don't you think this could be related to xkeyboard-config package (at least, not specific to rhythmbox) ?

Gnome default setup when Xorg keyboard is "fr"/"oss" leads to the "France Alternative" layout.

In this layout some application can't handle space caracter properly.
(See URL as some exemples).

Workaround is to force "France Alternative, latin9 only" in Gnome

or

change Xorg.conf replacing :

Option "XkbVariant" "oss"
by
Option "XkbVariant" "latin9"

Created an attachment (id=16310)
xorg.conf

Ludovic Lebègue (llebegue) wrote :

Some analysis on this bug

Xorg.conf :

Original one, not changed manually
Section "InputDevice"
        Identifier "Generic Keyboard"
        Driver "kbd"
        Option "CoreKeyboard"
        Option "XkbRules" "xorg"
        Option "XkbModel" "pc105"
        Option "XkbLayout" "fr"
        Option "XkbVariant" "oss"
EndSection

In GNOME keyboard preferences :

- "France Alternative" set with the "Reset to defaults" button => Rhythmbox KO
- "France" set with "Add +" button and chose variant "Default"

Ludovic Lebègue (llebegue) wrote :

"France" set with "Add +" button and chose variant "Default" => Rhythmbox KO

Ludovic Lebègue (llebegue) wrote :

In GNOME Keyboard preferences :
 - "France Alternative, latin9 only" => This is ok for rhytmbox

At this point, a change in GNOME is enough to solve this problem.

I guess it's not related to Rhythmbox but rather to the GNOME keybord layout ...

Sebastien Bacher (seb128) wrote :

GNOME only applies xorg keyboard settings

First of all, GNOME represents whatever is in base.xml. There is default French layout and several variants (including "oss" and "oss_latin9"). User choses whatever he wants. So I am not really sure what is the essence of your complain.

From the user's point of view there was no choice made when installing Ubuntu 8.04 (just picked a French keyboard without knowing the underlying mechanism).
In the end some functions are altered.

According to what I understand (and I have no real knowledge of the process)

1- User install X => picks a keyboard
2- X is somehow configured with XkbdLayout and XkbdVariant in /etc/X11/xorg.conf
3- GNOME picks these value and reads the associated entries in /etc/X11/xkb/base.xml to use them as default.

Step 1 and 2 above => This is the responsability of the linux distribution to configure xorg.conf. In Ubuntu it seems that debconf is the xorg.conf creation tool (according to the comment). Is this tool responsible to pick "oss" instead of "latin9" ?

What do you think ?

Another idea here : Perhaps is it simply the "oss" variant that is faulty and does not behave as expected ?

(In that case it seems to trigger a "ctrl+space" when the user press "space")

This is actually distro-specific, xkeyboard-config has nothing to do with it. FWIW fr(oss) produces space when space is pressed.

Let's take the following assumptions :

1 - configure manually xorg.conf (no distro involved here) to put "fr" variant "oss"
2 - use GNOME who accurately detects "France Alternative"
3 - try to search something in Rhythmbox involving a "space" caracter.
4 - it fails as if "ctrl+space" was triggered instead of "space"

I'm just trying to figure where the bug is...

The point is as for now it actually seems to be in "oss" because of the manual configuration step.

How can we make sure ?

You can easily check. Try running xev utility and press space

Just made a check with xev.
Everything seems fine at xev level.

From xev point of view pressing space returns char 20 => which indeed is a space.

My latest idea about "oss" being the source of the problem is not the good one.

Did you try the configuration to reproduce the bug ?

That is :

=> xorg.conf such as the attachment I made
=> Set 'France Alternative' as default keyboard in GNOME.

then

launch rhythmbox and try to search with something including a space caracter.

Changed in rhythmbox:
status: New → Fix Released

> Everything seems fine at xev level.
It means XKB is not in charge. So, it is really not ours, as I expected.

> launch rhythmbox and try to search with something including a space caracter.
Tried. Works ok. But space is actually not entered into the search line - it triggers play/pause thing. Which I guess it the rhythmbox normal behaviour.

Changed in xkeyboard-config:
status: Unknown → Confirmed
Ludovic Lebègue (llebegue) wrote :

On a fresh Ubuntu install (or an upgrade from previous version). What modifies the InputDevice section of xorg.conf (this could be a lead to the solution...) ?

Sorry to reopen again this one.

The default behavior of Rhytmbox is not to start playing when space is entered. The real short cut for this is ctrl+space.

This is the faulty behaviour started it all.

As for now the workaround for this bug is to change xorg.conf parameters.

Shouldn't that be a xorg problem ? Where is this analysis bad ?

If you look in the URL I have included you may also see that the same problem occurs in Quod Libet and CodeBlocks. Meaning that it is not tightly linked to Rhytmbox. https://bugs.launchpad.net/xkeyboard-config/+bug/221112

I have no slightest idea. In all layouts I use (Russian, USA) space triggers play/pause in Rhythmbox. I suggest addressing further question to Rhythmbox developers. Both oss and latin9 define SPCE as space on first shift level. I suspect this is the issue with modifiers (Ctrl) handling in Rhythmbox (or GTK). But this is just my guess.

Battle48 (mamouth-download) wrote :

[quote/] In GNOME Keyboard preferences :
 - "France Alternative, latin9 only" => This is ok for rhytmbox

At this point, a change in GNOME is enough to solve this problem.

I guess it's not related to Rhythmbox but rather to the GNOME keybord layout ... [/quote]

I changed the keyboard configuration to France 'alternative latin9 only' but the problem is not gone when I try to use rythmnbox.

Any idea ?

Ludovic Lebègue (llebegue) wrote :

@Battle48 : Try "France (Legacy) Alternative" and restart Rhythmbox

Battle48 (mamouth-download) wrote :

@Ludovic Lebègue : Thank you very much ! It works to perfection now =)
Thank you so much for your help =)

Binoul87 (morantbenjamin) wrote :

I reported this bug too but you were all faster tha me :) . I'll try this trick later !

Binoul87 (morantbenjamin) wrote :

Ok, evrything's clear with France (legacy) alternative! thx

Changed in rhythmbox:
status: Fix Released → Invalid
Changed in libgnomekbd:
status: Unknown → New
Creak (romain-failliot) wrote :

I don't know for you, but if I use the "France (Legacy) Alternative", it works until I reboot my system. After that, everything I wrote with my keyboard gives me stuff like "æâ€êþÿûîœô" as if "Alt Gr" was always pressed.

Changed in libgnomekbd:
status: New → Invalid
Changed in xkeyboard-config:
status: Confirmed → Invalid
Changed in rhythmbox:
status: Unknown → New
Changed in rhythmbox:
importance: Undecided → Medium
Changed in rhythmbox:
assignee: nobody → desktop-bugs
importance: Medium → Low
status: Confirmed → Triaged
Changed in libgnomekbd:
status: Invalid → New
Changed in rhythmbox:
status: Unknown → New
Changed in libgnomekbd:
status: Unknown → Confirmed
Changed in rhythmbox:
status: Unknown → Confirmed
Changed in rhythmbox:
assignee: desktop-bugs → seb128
assignee: seb128 → desktop-bugs
affects: rhythmbox (Ubuntu) → gtk+2.0 (Ubuntu)
affects: gtk+2.0 (Ubuntu) → rhythmbox (Ubuntu)
Martin Albisetti (beuno) on 2009-06-20
Changed in hundredpapercuts:
status: New → Invalid
Vish (vish) on 2009-08-24
affects: hundredpapercuts → null
Camille Appert (bibinou) on 2009-11-10
Changed in quodlibet (Ubuntu):
status: New → Confirmed
Mehdi Abaakouk (sileht) on 2010-02-24
Changed in listen:
status: New → Confirmed
Didier Roche (didrocks) on 2010-04-13
Changed in rhythmbox (Ubuntu):
importance: Low → High
assignee: Ubuntu Desktop Bugs (desktop-bugs) → Didier Roche (didrocks)
Didier Roche (didrocks) on 2010-04-14
Changed in rhythmbox (Ubuntu):
status: Triaged → Invalid
Changed in quodlibet (Ubuntu):
status: Confirmed → Invalid
Changed in xkeyboard-config (Ubuntu):
assignee: nobody → Didier Roche (didrocks)
importance: Undecided → High
status: New → Triaged
Changed in xkeyboard-config (Ubuntu):
status: Triaged → Fix Released
Changed in xkeyboard-config:
importance: Unknown → Medium
status: Invalid → Confirmed
Changed in libgnomekbd:
importance: Unknown → Medium
Changed in rhythmbox:
importance: Unknown → Medium
vhin8899 (gothicvhin-13) on 2010-09-18
Changed in rhythmbox (Ubuntu):
status: Invalid → New
status: New → Confirmed
Didier Roche (didrocks) on 2010-09-20
Changed in rhythmbox (Ubuntu):
status: Confirmed → Fix Released
Changed in xkeyboard-config:
importance: Medium → Unknown
Changed in xkeyboard-config:
importance: Unknown → Medium
Curtis Hovey (sinzui) on 2011-11-11
no longer affects: null
Bryce Harrington (bryce) on 2012-05-17
description: updated
Bryce Harrington (bryce) on 2012-05-17
no longer affects: rhythmbox (Ubuntu Precise)
no longer affects: quodlibet (Ubuntu Precise)
Changed in xkeyboard-config (Ubuntu Precise):
importance: Undecided → Medium
status: New → Fix Committed
importance: Medium → High
tags: added: regression-release
tags: added: verification-needed
tags: added: verification-done
removed: verification-needed
108 comments hidden view all 188 comments

And what if instead of
    include "nbsp(level4nl)"
we put non-breaking space to level 3. I find it more convenient (
    include "nbsp(level4n)"
    include "level5(rctrl_switch)"

And what if instead of level 4, we put non-breaking space to level 3. I find it is more convenient (and I think I am not alone).

So, instead of:
    include "nbsp(level4nl)"
we put non-breaking space to level 3:
    include "nbsp(level3n)"

This gives us back the Right-Ctrl. It does not break RhythmBox behaviour any more. And people using non-breaking spaces will be happy.

(In reply to comment #36)
> And what if instead of level 4, we put non-breaking space to level 3. I find it
> is more convenient (and I think I am not alone).
> So, instead of:
> include "nbsp(level4nl)"
> we put non-breaking space to level 3:
> include "nbsp(level3n)"
> This gives us back the Right-Ctrl. It does not break RhythmBox behaviour any
> more. And people using non-breaking spaces will be happy.

That's basically what fr-latin9 (the ancestor of fr-oss) used to do and it was changed to the current setting because too many people complained it made it too easy to type nbsp by mistake

(but now the nbsp behaviour is configurable so you should be able to override the default on your system if you wish)

Bryce Harrington (bryce) on 2012-06-26
Changed in xkeyboard-config (Ubuntu Precise):
status: Fix Committed → Triaged
Bryce Harrington (bryce) wrote :

The fix has been reverted out, due to a bug report (bug #1013881) filed about it during testing in -proposed.

You guys will need to work with upstream to find a better way of fixing it that doesn't cause regressions for anyone.

2012/6/26 Bryce Harrington <email address hidden>

> You guys will need to work with upstream to find a better way of fixing
> it that doesn't cause regressions for anyone.
>

Actually, on Fedora the shortcut for playing is Ctrl+Space and it works
just right.
It's simple, obvious and ok for everyone.

After discussions about the bug #1013881, it seems that the right way to solve this bug is to change the line 128 of symbol/fr
    include "nbsp(level4nl)"
by
    include "nbsp(level4n)"

For an unknown reason, the line «include "nbsp(level4nl)"» produces the bug of Rhythmbox.

This way, we can get :
– Right Ctrl works
– Rhythmbox Ctrl-Space works
– Nbsp is available (on level 4)

tags: added: verification-failed
removed: verification-done
Guillaume Martres (smarter) wrote :

I can confirm that the proposed fix in #155 (replace level4nl by level4n) is enough to fix ctrl-space in emacs(where it is a very frequently used key combination).

So, lads, with configurable nbsp - is there any solution that would make you all reasonably happy?

(In reply to comment #39)
> So, lads, with configurable nbsp - is there any solution that would make you
> all reasonably happy?

Is there a way to make the spacebar more neutral *except* for the combinations that trigger something else than space? The main complain seems to be that some apps want to grab space combinations (which is a really stupid idea IMHO) so can xkb work ass passthrough except for the specific combos used for nbspc?

I am honestly not sure how to translate that requirement into XKB terms...

I agree - intercepting those combinations is really odd. So I always have possibility to close this as WONTFIX. But if we manage to invent something - that would be better..

> can xkb work ass passthrough
It took me a while to parse that typo - was meditating over it for a minute;)

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.

> with too many types]. I do not have rythmbox, so I cannot test.
Can anybody with rhythmbox try that?

Guillaume Martres (smarter) wrote :

Any update on this? Emacs using the french keyboard is still broken under Saucy (see comment #156).

Hello,

Until a solution is to be found, could 518c769d be reverted for now? Breaking the very standard behavior of right control in all applications (e.g. xterminals!!) is really not acceptable, compared to the few issues that the behavior has without it.

Samuel

(In reply to comment #44)
> Hello,
>
> 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

It's exactly the same mechanism as endorsed in other official French layouts like the Canadian one

Download full text (4.9 KiB)

(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 || ...

Read more...

For some reason, I found myself using the 'fr oss' layout in Gnome 3.10. And I must say that finding out that this layout was picked as the default left me speechless: two keys on my keyboard no longer behave according to what's *on* the actual key:

 - the right control key, which just says "Ctrl", just like its left counterpart,
 - and the keypad's del/dot key which has an actual dot on it, not a comma

Both of those changes are incomprehensible. Whether *alternative* layouts exist to provide new mappings is of no issue to me. But a layout touted as the default layout should respect what's *engraved* on keyboards.

FTR, the original 'fr' layout also has that keypad dot/comma issue but not the right control mapped to Level5, but at least there's an "kpdl:dot" option to fix the former. So I fumbled through Gnome's ever-changing control panel and managed to change back to it.

(In reply to comment #46)
> 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.

+1, all the French PC keyboards I have owned for the past 15 years have been like this. I can only add my voice to let it be known that having to fix my keyboard layout for correct operation was quite upsetting.

Anyhow, thanks to all for looking into it.

I spent a couple days extremely disappointed to have a broken right [CTRL] key on a french keyboard on recent Arch installs, thus being unable to use VirtualBox properly, and googling around (and let me tell you that my googling showed me a *lot* of french people are really upset with this as well) I finally found out that this breakage comes from this commit :

http://cgit.freedesktop.org/xkeyboard-config/commit/symbols/fr?id=518c769df2e9ce70cb721769a08b81504f243b2a

( http://goo.gl/SWU8Is )

Let me tell you that this breakage of right [CTRL], assigning it to ANOTHER function than right [CTRL] is completely inappropriate and upsetting.

I therefore hereby specifically request this absurd modification to be reverted.

More arguments in favor of reverting to an normal behaviour of Ctrl-R:
-- Most computers in most operating systems, languages (including French until recently), desktops... have two identical Ctrl keys. It is queer to have French keyboards doing otherwise since a few years.
-- Like having two Shift keys, two Ctrl keys are better for easy fast typing.

By the way, breaking the French keyboard breaks the Belgian keyboard too.

Could someone create poll on some french(belgian) web site, linux-oriented. Which behavior would be preferable?

(In reply to comment #50)
> Could someone create poll on some french(belgian) web site, linux-oriented.
> Which behavior would be preferable?

Is this even necessary? I mean, the change wasn't made in the first place because an user wasn't happy with the state, but because some apps couldn't handle it. And nowadays, at least some of those apps (Rhythmbox, Totem, …) have been fixed or altered in a way they do not suffer from it anymore, actually mostly nullifying the original point.

Also, what a poll would do? This looks like a pretty subtle problem to me, and an uneducated user couldn't really tell. As far as they are concerned, I would think they just want everything working.
Even me, if you ask I would say (as in my previous reply) just fix the XLookupString while keeping the original mapping, since IIUC it would fix everybody's issue. But I have no real clue whether it's a pertinent answer or not.

That was just an idea. As usual, when there are controversies... Trying to be democratic:)

(In reply to comment #50)
> Could someone create poll on some french(belgian) web site, linux-oriented.
> Which behavior would be preferable?

A poll would be pointless as its representativeness would be very hard to determine.
Most users don't care "as long as it works" and may not even know there is a poll somewhere.

The matter is : French keyboard have, and have always had since the PC keyboards exist (that makes 30 years), 2 similar [CTRL] keys that have the same printed label and are expected to exhibit the same behaviour.

AND THEY ALWAYS HAVE BEEN SO IN ANY LINUX OR "other OS" keymaps, and especially default keymaps - if anybody wants to customize HER keyboard, then it's HER choice, but by no means a default.

OTOH French keyboard have a left [Alt] key and a right [AltGr] keys having different labels and expected to have different roles.

This is extremely clear. Both [CTRL] keys should act as [CTRL] keys. Left one, rigth one, period.

Some softwares - such as Virtualbox - will want to use the left or right CTRL key for some specific role, and then it's printed in their documentation and the corresponding key is supposed to exist and be correctly mapped. It is nonsense to find oneself with a keymap in which some highly classical and standard key just doesn't happen to exist anymore just because of a once-upon-a-time existing issue (since solved) with a shortcut on a music player that nobody cares about !?!?!? You don't want to break a professional keyboard just because of arguable choices in a toy !

Le 13 mars 2014 04:56, "Swâmi Petaramesh" <email address hidden> a
écrit :
> I finally found out that this breakage comes from
> this commit :
>
> http://cgit.freedesktop.org/xkeyboard-
> config/commit/symbols/fr?id=518c769df2e9ce70cb721769a08b81504f243b2a
>
> ( http://goo.gl/SWU8Is )

I remember that the nbsp behavior was a PITA because most of the apps
doesn't handle nbsp, but regular space instead. That said, I don't see the
link with the right Ctrl. Do you have any idea?

So, finally, is everybody happy with me removing that line:

include "level5(rctrl_switch)"

? If no objections within next week - I will just drop it.

I had yet another good reason to revert to a "normal right [CTRL] key" on a Fedora this morning:

I was working in a terminal with several open terminal tabs. Switching between tabs is made using [Ctrl]-[PageUp] and [Ctrl]-[PageDown] - same goes with other Gnome tabbed apps, as well as Firefox and Chromium...

If you have a working right [Ctrl] key, switching tabs is easy, you just need 2 fingers from your right hand.

If you don't have a working right [Ctrl] key, you need both hands.

Having the broken right [Ctrl] key was so annoying at work, that I had to fix it immediately.

(In reply to comment #54)
> So, finally, is everybody happy with me removing that line:
>
> include "level5(rctrl_switch)"

No, just didn't see the point of restating what has already been written before

A level 5 map needs a level 5 switch, iso defined right ctrl as default level 5 switch so there is no better option available, and users who do not care about the fifth level can choose another spacebar variant since they are configurable.

Repeating :

1/ Standard French keyboard has NO [CtrlGr] key. It does have 2 normal [Ctrl] keys bearing the exact same label. The right [Ctrl] key actually is a right [Ctrl] key and no other modifier or whatever.

2/ There are quite a *lot* of common, daily used by professional IT staff, keyboard shortcuts or combinations such as [Ctrl]-[Arrows], [Ctrl]-[PageUp/Down], [Ctrl]-[Home], [Ctrl]-[End], plus all such combinations adding [Shift], then [Ctrl]-L, [Ctrl]-M...

-> All these day-long used combinations can be conveniently played with 2 (or 3) fingers when the right [Ctrl] key actually is a right [Ctrl] key, and changing this key breaks them all, needing people to start using both hands for typing what they have typed with 2 fingers for 30 YEARS ! And mistype. And mistype. And mistype.

3/ The issue with Rythmbox looks solved for long, and who wants to break professional use of a keyboard for a solved bug in a music player ?

4/ Nobody (normal user) I talked to has ever heard about a "level 5" story, nor do people give a damn.

5/ Everybody wanting to type non-breakable space in word processors (LibreOffice...) do it with [Ctrl]-[Shift]-[Space] and don't need a specifically modified right Ctrl for that.

6/ Breaking right [Ctrl] breaks other apps that specifically request it NOT to be broke, such as [VirtualBox] - again professional stuff.

Breaking the right [Ctrl] keys on the french keyboard is plain stupid, period.

I never heard of or used the level5 either, but to solve the issue could we maybe put it in another layout? For example something like "oss-level5"?

I personally have to patch the file on every package update and even if I'm used to that and have the patch ready now, it gets annoying. On my laptop the right Ctrl key is adjascent to the arrows and it's way more convenient to be able to move through words in a text using only the right hand.

Even though I've been an IT professional for the past 3O years, I went to a large computer store in France over lunch time, to find out if such thing as a [CtrlGr] key could possibly exist on a french keyboard.

Let me tell you : I couldn't find any.

OTOH, I was surprised to notice that some tablets with removable keyboards, as well as some ultrabooks with space-saver keyboards, did not have a right [Ctrl] key at all !

All have a left [Ctrl], left [Alt] and right [AltGr].

The vast majority of times, they have a right [Ctrl] key which is similar to the left one.

But sometimes there is no right [Ctrl] at all !

This single fact prohibits a standard keymap giving a different assignation to the right [Ctrl] key, because this key may well not even exist on a given keyboard ! Thus you cannot rely on it for any feature that could be positively necessary.

That makes Yet Another Good Reason™ to keep the good 'ole behaviour of having 2 similarily mapped [Ctrl] keys.

Gentlemen, I am really stuck at that point. I am refusing to make any changes before there is either some kind of agreement - or there are some minimally conclusive voting results.
I do not take any sides (I cannot have any personal opinion, not using French). I am just freezing the situation.

Download full text (3.8 KiB)

All answers ask to perform the change. How is that not an agreement? I was
hoping to get it in this release of Ubuntu. Alas.

2014-04-18 1:06 GMT+02:00 Sergey V. Udaltsov <email address hidden>:

> Gentlemen, I am really stuck at that point. I am refusing to make any
> changes before there is either some kind of agreement - or there are some
> minimally conclusive voting results.
> I do not take any sides (I cannot have any personal opinion, not using
> French). I am just freezing the situation.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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...

Read more...

Sergey, you might want to check Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/1013881 , which is a "downstream reflection" of this one.

There are some other "loud voices" there that you might consider as taking part to the "vote" that you want.

I had in my office 2 peopl that complained about this, this month. Maybe you could count them as well ?

BTW Sergey, I'm a bit surprised that you want a "vote" to fix something that people complain about, when you didn't need any vote to break it in the first place...

Would you need a vote, I suggest that you put a survey system online by yourself on any web page that you'd like (so you know the vote is "impartial"), and we let people know about it...

If you asks for a vote, it sounds logical that you organize it.

I feel extremely uneasy because I am a user of free software and I am full of respect and gratitude for the people who make this possible, including of course Nicolas Mailhot. I am an amateur and I am conscious that I rely entirely on the work of devoted paid and unpaid professionals.

But in this case, I must crudely say, because it was hinted that we should have a vote: the vote already happened, here in Bugzilla, and in Launchpad, and elsewhere in many forums. The result obviously is: Nicolas Mailhot against the rest of the world.

I think the rest of the world constitutes a majority compared to Nicolas Mailhot alone. Therefore one should immediately revert to the last good version with two Control keys.

(In reply to comment #60)
> Gentlemen, I am really stuck at that point.

Allow me to sum it up.

 - Nicolas is the sole advocate of having Control_R mapped to Level5.
 - The rest of us want to go back to having both left and right Control behaving the same way.

I'm not quite sure how you want us to organize a vote or poll. French Linux users (just like non-French ones) use a variety of distributions (which, BTW, may not ship the changed version of xkeyboard-config), and may not even all use a French keyboard (I'd say roughly half of my Linux-using friends and coworkers are using US qwerty layouts or mac layouts).

Since apparently no hardware maker is following ISO standards, may I suggest creating new layouts such as "oss-iso" with Nicolas' changes?

As one of Gentoo's X11 maintainers, I am really tempted to just revert that change downstream. The few French users I have talked to were just as surprised as I was to lose their Control_R key for no apparent reason.

I could organize a poll on my blog but being aggregated only on Planet Gentoo, I wouldn't give much credit to any numbers I could find.

Creak (romain-failliot) wrote :

I'm French and I think left and right control keys should behave the same as in every other normal french layouts.

Here is a survey for those in here that want to give their opinion:
http://doodle.com/i3f5vpiaqk37ebms

I agree with Remi, I understand we want to follow the ISO standard, but if the standard isn't appreciated by most of the users, we should create a new "oss-iso" layout.

Creak (romain-failliot) wrote :

Hah... actually I'm the one that reported that bug 6 years ago! I didn't even remember...
I think it's time to close this bug once and for all. So please, vote ;)

Great ! Now the FR right [Ctrl] is B.R.O.K.E.N on Ubuntu 14.04 as well.

Given the number of french Ubuntu users (+ upcoming derivatives) I think you'll have your "vote" and "survey" very soon, just by taking a look at lauchpad bug entries and new comments on https://bugs.launchpad.net/bugs/1013881 - which are not reflected here - some of the latest ones being very hmmm... "vocal".

Displaying first 40 and last 40 comments. View all 188 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.