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

[Creak]

[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

[Patrick Kilgore (patrick-kilgore)]

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?

[Creak (romain-failliot)]

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)]

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)]

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

[Patrick Kilgore (patrick-kilgore)]

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)]

Here is my xorg.conf

[Creak (romain-failliot)]

Here is mine

[Ronan Jouchet (ronj)]

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

[Patrick Kilgore (patrick-kilgore)]

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!

[Patrick Kilgore (patrick-kilgore)]

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

[Ludovic Lebègue (llebegue)]

Here is the gnome keyboard config.

[Patrick Kilgore (patrick-kilgore)]

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!

[blahnotblahblah (coufan)]

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!!!

[Sika (sikamikaniboots)]

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) ?

[Ludovic Lebègue (llebegue)]

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"

[Ludovic Lebègue (llebegue)]

Created an attachment (id=16310)
xorg.conf

[Ludovic Lebègue (llebegue)]

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)]

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

[Ludovic Lebègue (llebegue)]

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)]

GNOME only applies xorg keyboard settings

[Sergey V. Udaltsov (svu)]

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.

[Ludovic Lebègue (llebegue)]

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 ?

[Ludovic Lebègue (llebegue)]

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")

[Sergey V. Udaltsov (svu)]

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

[Ludovic Lebègue (llebegue)]

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 ?

[Sergey V. Udaltsov (svu)]

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

[Ludovic Lebègue (llebegue)]

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.

[Sergey V. Udaltsov (svu)]

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

[Ludovic Lebègue (llebegue)]

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...) ?

[Ludovic Lebègue (llebegue)]

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 ?

[Ludovic Lebègue (llebegue)]

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

[Sergey V. Udaltsov (svu)]

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)]

[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)]

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

[Battle48 (mamouth-download)]

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

[Binoul87 (morantbenjamin)]

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

[Ludovic Lebègue (llebegue)]

For reference here is the bug to GNOME
http://bugzilla.gnome.org/show_bug.cgi?id=531279

[Binoul87 (morantbenjamin)]

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

[Creak (romain-failliot)]

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.

[Battle48 (mamouth-download)]

Sorry Creak,

Even when I reboot the system, everything continues to work just fine with 'France (legacy) alternative'.

So I can't help you. Sorry.

I hope somebody else can give you some help.

[roman.rene (roman-rene)]

I applied the France (legacy) alternative trick a week ago.
It worked just fine until today .. i have now the same problem Creak related (æâ€êþÿûîœô characters )

The thing is that bug is not constant; it comes ans goes ...

[Battle48 (mamouth-download)]

For me, it has never gone so far. Sorry for this inconstance guys..

[Ludovic Lebègue (llebegue)]

As seen on https://bugs.launchpad.net/xkeyboard-config/+bug/221112, a workaround is in "/etc/X11/xkb/symbols/fr" to replace this :
    include "nbsp(level4nl)"
by this :
    include "nbsp(level4n)"

Does that help ?

It also seems to be related to https://bugs.freedesktop.org/show_bug.cgi?id=9529

[Sika (sikamikaniboots)]

I think this bug is related to LP bug #198759 and https://bugs.freedesktop.org/show_bug.cgi?id=9529.
Still a problem with French narrow non-breaking space handling I think.
A small workaround that worked for me: in "/etc/X11/xkb/symbols/fr" replace this :
    include "nbsp(level4nl)"
by this :
    include "nbsp(level4n)"

I hope it'll help...

[Ludovic Lebègue (llebegue)]

Silka : your workaround works great with "France Alternative" layout (fr oss)

[Sergey V. Udaltsov (svu)]

> Does that help ?

Do you ask me? Since you're reporter - it's up to you to make sure it works for you;)

[Ludovic Lebègue (llebegue)]

From the user point of view (this is mine) it helps indeed.

Can this help to find a solution ?

[Ludovic Lebègue (llebegue)]

I mean a solution suitable to everybody ... not only me :)

[Sergey V. Udaltsov (svu)]

Actually this nbsp(level4nl) was offered by Nicolas. I think it would be good if you settle this issue (see bug #9529)

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

I don't have any magic solution:

1. if some apps misbehave when ctrl+space is used by the xkb layout they should be fixed by their upstream. xkb layouts are a fact of life which means apps have to deal with them gracefully

2. plus with multimedia keyboards so common nowadays almost every home keyboard will have a dedicated start/pause key, so trying to grab ctrl+space is not necessary

3. in the meanwhile you're free to try the other nbsp options. I made this key configurable for a reason — none of the options work well in every case so users are free to chose their lesser evil. When the other default were set other people complained for other reasons

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

Though the situation may get a bit better if someone took the time to figure why RControl and LControl are not defined by default in xkb. I used Control instead because I didn't want to risk side-effects by distinguishing between both control keys when the default layout didn't. If RControl and LControl were cleanly separated one of them would be left for apps to use with space.

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

Also depending on where in gtk the bug occur changing level4nl to

// level4nl provides narrow no-breaking space in addition to the normal one
// without forcing the use of level5 for mostly four-level layouts
// Used by fr(oss), be(oss)…
partial
xkb_symbols "level4nl" {
 key <SPCE> {
   type[Group1]="LOCAL_EIGHT_LEVEL",
   symbols[Group1]= [ space, space, NoSymbol, nobreakspace, NoSymbol, 0x100202F, NoSymbol, NoSymbol ]
 };
};

may limit the occurrence of such side-effects

[Ludovic Lebègue (llebegue)]

I've just tried this latest configuration.
It doesn't change the behavior of the incriminated application but now no modifiers

Space key alone in xev :

KeyRelease event, serial 31, synthetic NO, window 0x2200001,
    root 0x13b, subw 0x0, time 550680493, (85,98), root:(1666,147),
    state 0x10, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

Left control + space :

KeyPress event, serial 31, synthetic NO, window 0x2200001,
    root 0x13b, subw 0x0, time 550711435, (91,86), root:(1672,135),
    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 31, synthetic NO, window 0x2200001,
    root 0x13b, subw 0x0, time 550714067, (91,86), root:(1672,135),
    state 0x14, keycode 65 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

Right control + space :

KeyPress event, serial 31, synthetic NO, window 0x2200001,
    root 0x13b, subw 0x0, time 550783309, (88,289), root:(1669,338),
    state 0x10, keycode 109 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 31, synthetic NO, window 0x2200001,
    root 0x13b, subw 0x0, time 550784541, (88,289), root:(1669,338),
    state 0x14, keycode 65 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

Then I'm afraid you'll have to convince application developpers some layouts actually use the spacebar to output spaces and they can't assume ctrl+space is available for them to use.

[Ludovic Lebègue (llebegue)]

I'll try to do that. As for now I close this bug.
Thanks for your help.

[Creak (romain-failliot)]

Cool, it works with the default keyboard layout too!

[Ludovic Lebègue (llebegue)]

After having tried hypothesis the best shot is that it 's a Rhythmbox bug that should not handle CTRL+space as a shortcut in French. (because of a specific french typograhy exception => small unbreakable space ...)
This is very unlikely to change in Rythmbox, but I'll fill a bug there.

[Sebastien Bacher (seb128)]

the bug is not about ctrl-space but using space in this text entry, no?

[Ludovic Lebègue (llebegue)]

Yes and according to https://bugs.freedesktop.org/show_bug.cgi?id=15804#c23 it seems related to a short-cut choice in Rhythmbox.

[Camille Appert (bibinou)]

Also affects quodlibet.

[perfran (perfran)]

I have the same bug with "french other" layout but not with "french"

[Alexis Bauchu (alexis-bauchu)]

For the moment, the problem is solved by switching to "France (Legacy) Alternative", but I haven't tried to reboot the system nor X11.

Rhythmbox is the first program to show this problem (for example Firefox + Ubiquity works pretty fine as "space" and "ctrl+space" are handled differently).

[ktulu77 (ktulu-highwaytoacdc)]

I have this problem on my laptop (XPS 1530) and my desktop computer.
If I change in the agency the option "Using space key to input non-breakable space character" to the second option (Space key outputs usual space at any level") the problem disappears on both computers.

Someone should change the priority, the search box is unusable with this bug with a french config.

[roman.rene (roman-rene)]

Still the same bug on Intrepid alpha 6 .
Thanks.

[Christophe Mehay (goldy-goldenfish)]

I found a way to fix the bug :

Go to gnome keybord configuration and see the attachement...

[Creak (romain-failliot)]

It's almost 6 months since I reported this bug. We've found workarounds, but what is the problem about fixing it? Actually I don't understand. I'd be glad if someone could enlighten me.

[Ludovic Lebègue (llebegue)]

As far as I understand the situation.

=> a french keyboard layout was designed to take care of specific needs of french typography, and that's ok.
=> some applications such as Rhythmbox should be changed not to use a given key or combination of keys (here we are talking about space key as a trigger for play/pause on Rhythmbox)
=> BUT ... a decision is to be taken :
          => use a media key that can be found on new keyboards (but not everybody as such a keyboard)
          => pick a new key combination at the cost of being less user friendly

In short, it looks like a dead end and we only have workarounds for us.

[Creak (romain-failliot)]

Then why the space bar works in totem? They've found a workaround or there is a subtlety?

[Laurent Dinclaux (dreadlox)]

Problem is still there in Intrepid RC... since Hardy....

Still hasn't been solve. There is a problem with default keyb layout chosen by installer and Rhythmbox

Please solve it thks.

[roman.rene (roman-rene)]

Goldy's solution works fine (see above)
maybe it should be default configuration for French keyboard...

[Antoine Pairet (b-ly)]

As far as I am concerned, changing the layout of the keyboard from "French Alternative" to "French" solves the issue. The difference between the layouts for the space key is that in "French Alternative", it is "nobreakspace".

In fact, the default installation select the "French Alternative" layout when choosing a french keyboard. I think this should be changed in the installer.

[Oncle Tom (oncletom)]

I had the problem in Hardy and now Intreprid with "French other" keyboard mapping.

Solved by the comment #41 : https://bugs.launchpad.net/ubuntu/+source/quodlibet/+bug/221112/comments/41

[Benziane Chakib (spykspygel)]

I had noticed the same bug with Scite and the "c.api" API , as all of you i'm using a French layout keyboard .

The Goldy's fix works fine though .

[Miles Prower (mprower)]

Confirming bug. Keyboard layout used on the machine is: fr oss (⇒ setxkbmap fr oss).

The French Alternative keyboard is (imho) the best available layout for french keyboards… except you can't do a ñ easily and it's quite a shame since a lot of people speaks Spanish too where I live. The space bar is not a nonbreakingspace as far as I know, as all other applications (including OpenOffice.org) reckon it as a regular space.

To do a nbsp in OpenOffice.org, you have to use CTRL+Shift+Spacebar (cumbersome: CRTL+Space was a lot better in OOo2, OOo3 behavior is copied from Microsoft Office).

[antistress (antistress)]

see also

Bug 541466 – Ignoring keyboard modifiers with some keyboard layouts (gtk+)
http://bugzilla.gnome.org/show_bug.cgi?id=541466

Bug 534268 – Typing the space key to perform a search while watching a video does in fact "pause" (totem)
http://bugzilla.gnome.org/show_bug.cgi?id=534268

[Creak (romain-failliot)]

@Miles Prower: to do a ñ you can simply do this combo AltGr+^ then n.
In general, AltGr+^ is the ~ accent, like Shift+^ is the ¨ accent.

[Opoho (opoho)]

Problem still there with shiny Jaunty...

[meuns (sylvainmeunier26)]

Indeed. The Goldy's trick works.

[Green Fish (lgardent)]

I confirm. Using Jaunty with the standard french kb layout : same lame problem. But this should be a rhythmbox problem, not a global xorg/gnome issue. Wouldn't it be just much easier if an option tab in rhythmbox enabled users to se their own shortcuts ? (as VLC does).

[Green Fish (lgardent)]

oh, and, sorry, for double posting : the problem occurs also on archlinux and fedora, nothing specific about ubuntu here.

[Stéphane Maniaci (stephh)]

Please fix this bug for Karmic, it's really annoying and makes search in Rhythmbox a pain for us french users.

[Creak (romain-failliot)]

Maybe this could be one of the but to fill in the "One Hundred Paper Cuts".

[curly18 (curly18)]

I had the same problem with rhythmbox (with the french keyboard layout), but I fixed it in Sytème>Préférences>Clavier>Options de l'agencement then under "Utiliser la barre d'espacement pour insérer un espace insécable I used "La barre d'espacement renvoie un espace ordinaire à tous les niveaux". Now I can insert a space in the search field of rhythmbox, and I DO can play/pause when my cursor isn't in the search field. It didn't affect other applications, and works perfectly. I hope it helps, maybe this setting should be by default in the french ubuntu

[Martin Albisetti (beuno)]

Thank you for bringing this bug to our attention. Unfortunately a paper cut should be a small usability issue that affects many people and is quick and easy to fix. I'm afraid this bug can't be addressed as part of this project.
A paper cut is a minor usability annoyance that an average user would encounter on his/her first day of using a new installation of Ubuntu 9.10.

[antistress (antistress)]

Is it possible to sum up things for non technical people?
What is responsible for this long standing bug ?

For instance i still can't add a space by pressing the space key in KeepNote (crossplatform pyGTK application).
Very annoying for french users. Please french users matter!

Besides the bug related to libgnomekbd package doesn't seem to be the good one

[antistress (antistress)]

(tip given in comment 60 worked for me)

[Olivier Grégoire (ogregoire)]

I could reproduce the error using a fr-BE Ubuntu with Belgian keyboard-layout. So it is not only related to the French layout.

[Philippe (pcreux)]

I fixed this bug with Keyboard layout: France Alternative

- In System => Preferences => Keyboard
- In Layout tab
- Click Layout Options
- Expand the latest option: Using space keyto input non-breakable space character
- Select Usual space at any level

No need to restart X nor Rythmbox: it works straight away.

Hope it helps!

[Laurent Dinclaux (dreadlox)]

Workaround have been found but still no fix.... Karmic has the bug too on a fresh french install.

On karmic the workaround is 'France Autre, latin-9 seulement'

[antistress (antistress)]

Not being able to control the PC with the keyboard looks like a top first priority bug to me and obviously developers doesn't seem to care enough about that bug.
Sometimes Ubuntu looks like it's made for english speaker human being only

[Fabien (fabmisc3)]

@Philippe

I fixed a space problem with Code:Blocks IDE the same way. Just like you say :
by the way english version of ubuntu but french keyboard.

I am pretty sure this is the best way to fix this problem.

[Creak (romain-failliot)]

The bug filled in bugzilla (https://bugzilla.gnome.org/show_bug.cgi) has been resolved "NOTGNOME".
I don't know, maybe we should be a bit more active, but how?
Should we ask help from Rhythmbox, X.org, GNOME, ... ?

[Creak (romain-failliot)]

Sorry, bad link! https://bugzilla.gnome.org/show_bug.cgi?id=530123

[Sebastien Bacher (seb128)]

> Not being able to control the PC with the keyboard looks like a top first priority bug to me and obviously developers doesn't seem to care enough about that bug.

Do you know of any desktop user not having a pointer device nowadays? The bug concern one layout only and seems a minor inconvenient, using the french keymap I never ran in that buggy corner situation, it would be nice to get fixed still but there are lot of other issues in ubuntu to work on some being crashers, security issues, annoyance in something you use daily, etc

[antistress (antistress)]

Sebastien : adding a space with the mouse is not trivial
You have to open a document with spaces in it, then use right-click to copy & paste the space each time you want to add another word separated with a space to a sentence.
Of course it's possible but...
The space bar is largely used on a day-to-day basis and not having it working prevents the user to write text with its computer. Not a minor bug for french users, honestly

[Sebastien Bacher (seb128)]

> The space bar is largely used on a day-to-day basis

it's not like the space bar was not working, it's broken in rhythmbox widget, you can't really say than searching for song name with a space in their title is a basis ubuntu feature, sure it can be annoying but it's quite a corner case there

[antistress (antistress)]

Sebastien : ok, thats' my fault i didn't tell you the whole picture
The bug not only occurs in rhythmbox, several applications are concerned.
For instance i make use of KeepNote for taking notes and space bar doesn't work either

keepnote webiste http://rasm.ods.org/keepnote/
related bugs in keepnote :
http://code.google.com/p/keepnote/issues/detail?id=101
http://code.google.com/p/keepnote/issues/detail?id=8
http://code.google.com/p/keepnote/issues/detail?id=1

[antistress (antistress)]

(the bug used to happen also in YouTube plugin for Totem)

[®om (rom1v)]

The problem still exists in karmic :(

[Emmanuel Pacaud (emmanuel-pacaud)]

I have this issue on a fresh stable karmic install on my 2 machines. I'm pretty sure I've not changed the default french keyboard layout during the installation.

[Emmanuel Pacaud (emmanuel-pacaud)]

My keyboard layout is "France autre", by the way.

[ktulu77 (ktulu-highwaytoacdc)]

Still here on karmic too on my computer.

I don't understand why this bug is not fixed. There is already a workaround : enable just one checkbox in the keyboard preferences (Sytème>Préférences>Clavier>Options de l'agencement then under "Utiliser la barre d'espacement pour insérer un espace insécable check "La barre d'espacement renvoie un espace ordinaire à tous les niveaux). Why is this not done by default ?

This bug is here for more than a year, with a solution. I use ubuntu with this workaround for a long time, and I never had any problems. It is clear that no one knows how to fix the source of this bug but the workaround works well, and is just on the french keyboard layout (so it is not dangerous and the risk of regressions is very small).

Rhythmbox is one of the main app of Ubuntu and the french community of ubuntu is important. Could someone just enable this checkbox by default please.

[Creak (romain-failliot)]

A workaround is not a bug fix... And doing a special treatment for foreign
language is definitely not a bug fix either (i'm french BTW).
I think the bug should just be fixed by the developers (I don't care if it's
one of Rhythmbox or of GNOME or X.org). And I also think it's a shame that
more than a year after the bug appears in launchpad, the bug is still active
and even though not fixed!

What should we do to be heard? Maybe open a brainstorm idea?

Please subscribe to this idea as fast as possible so that the admin can't
say "it's just a bug..."
http://brainstorm.ubuntu.com/idea/22277/

[ktulu77 (ktulu-highwaytoacdc)]

I am ok, a workaround is not a bugfix, but you can see several bugs in launchpad fixed with work arounds.
Look this one : https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/290204

The pcskeaker has simply been blacklisted to fix a bug that no one knows where is the problem. It is more bad than just change the state of a checkbox by default for a language.

Perhaps this bug (with pcskeakers) has been marked has fixed because it was in one hundred paper-cut project I don't know...

Anyway, I am going to vote for your idea as soon as it has been validated.

[Creak (romain-failliot)]

Didn't know it had to be validated, I hope it will be too ;)
The solution I proposed (because we have to propose at least one solution) is simply to select the option for every language.
Because I think there are also other keyboard layouts that has this problem and because I don't understand the interest of this option.

[Sebastien Bacher (seb128)]

> What should we do to be heard?

you are read but you got the issue wrong there, it's not that people deny there is a bug or that it should be fixed but there is simply no keyboard export in the ubuntu team and nobody seems to have a clue about what to change there

[Sebastien Bacher (seb128)]

you could try to suggest that change upstream too and wait for comments there

[Sebastien Bacher (seb128)]

the issue is not specific to rhythmbox either

[Creak (romain-failliot)]

yup.
how do you report a bug upstream?

[antistress (antistress)]

see also (Totem YouTube plugin)
https://bugzilla.gnome.org/show_bug.cgi?id=541466

[Camille Appert (bibinou)]

Hi,
Can someone (with a working setup) run 'xev' in a terminal and tell me what is the output when you press Ctrl+Space and when you press only space ?

I applied the fix successfully, but as I was messing around with the keyboard properties it doesn't work anymore, even with France (Autre) and the "insérer un espace insécable à tous les niveaux" fix.

Here is mine (commented) :

// pressing left Ctrl

KeyPress event, serial 35, synthetic NO, window 0x4000001,
    root 0x13c, subw 0x0, time 18642052, (357,607), root:(1011,803),
    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

// pressing space

KeyPress event, serial 35, synthetic NO, window 0x4000001,
    root 0x13c, subw 0x0, time 18644612, (357,607), root:(1011,803),
    state 0x14, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XmbLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

// releasing space

KeyRelease event, serial 35, synthetic NO, window 0x4000001,
    root 0x13c, subw 0x0, time 18644765, (357,607), root:(1011,803),
    state 0x14, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

// releasing control

KeyRelease event, serial 35, synthetic NO, window 0x4000001,
    root 0x13c, subw 0x0, time 18646482, (353,602), root:(1007,798),
    state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

------------------ pressing only space : ------------------

KeyPress event, serial 35, synthetic NO, window 0x4000001,
    root 0x13c, subw 0x0, time 18859543, (348,283), root:(1002,479),
    state 0x10, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XmbLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

KeyRelease event, serial 35, synthetic NO, window 0x4000001,
    root 0x13c, subw 0x0, time 18859659, (348,283), root:(1002,479),
    state 0x10, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

[Creak (romain-failliot)]

I don't know what your fix is, but it seems to work, here is my output:

// pressing left Ctrl

KeyPress event, serial 36, synthetic NO, window 0x4400001,
    root 0x1a7, subw 0x0, time 4885397, (45,174), root:(1474,224),
    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

// pressing space

KeyPress event, serial 36, synthetic NO, window 0x4400001,
    root 0x1a7, subw 0x0, time 4885613, (45,174), root:(1474,224),
    state 0x14, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (00) ""
    XmbLookupString gives 1 bytes: (00) ""
    XFilterEvent returns: False

// releasing space

KeyRelease event, serial 36, synthetic NO, window 0x4400001,
    root 0x1a7, subw 0x0, time 4885732, (45,174), root:(1474,224),
    state 0x14, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (00) ""
    XFilterEvent returns: False

// releasing control

KeyRelease event, serial 36, synthetic NO, window 0x4400001,
    root 0x1a7, subw 0x0, time 4885877, (45,174), root:(1474,224),
    state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

------------------ pressing only space : ------------------

KeyPress event, serial 36, synthetic NO, window 0x4400001,
    root 0x1a7, subw 0x0, time 4886421, (45,174), root:(1474,224),
    state 0x10, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XmbLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x4400001,
    root 0x1a7, subw 0x0, time 4886517, (45,174), root:(1474,224),
    state 0x10, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

[Philippe (pcreux)]

Same output as Creak.

φ

On Wed, Nov 4, 2009 at 11:12, Creak <email address hidden> wrote:
> I don't know what your fix is, but it seems to work, here is my output:
>
> // pressing left Ctrl
>
> KeyPress event, serial 36, synthetic NO, window 0x4400001,
>    root 0x1a7, subw 0x0, time 4885397, (45,174), root:(1474,224),
>    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
>    XLookupString gives 0 bytes:
>    XmbLookupString gives 0 bytes:
>    XFilterEvent returns: False
>
> // pressing space
>
> KeyPress event, serial 36, synthetic NO, window 0x4400001,
>    root 0x1a7, subw 0x0, time 4885613, (45,174), root:(1474,224),
>    state 0x14, keycode 65 (keysym 0x20, space), same_screen YES,
>    XLookupString gives 1 bytes: (00) ""
>    XmbLookupString gives 1 bytes: (00) ""
>    XFilterEvent returns: False
>
> // releasing space
>
> KeyRelease event, serial 36, synthetic NO, window 0x4400001,
>    root 0x1a7, subw 0x0, time 4885732, (45,174), root:(1474,224),
>    state 0x14, keycode 65 (keysym 0x20, space), same_screen YES,
>    XLookupString gives 1 bytes: (00) ""
>    XFilterEvent returns: False
>
> // releasing control
>
> KeyRelease event, serial 36, synthetic NO, window 0x4400001,
>    root 0x1a7, subw 0x0, time 4885877, (45,174), root:(1474,224),
>    state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
>    XLookupString gives 0 bytes:
>    XFilterEvent returns: False
>
> ------------------ pressing only space : ------------------
>
> KeyPress event, serial 36, synthetic NO, window 0x4400001,
>    root 0x1a7, subw 0x0, time 4886421, (45,174), root:(1474,224),
>    state 0x10, keycode 65 (keysym 0x20, space), same_screen YES,
>    XLookupString gives 1 bytes: (20) " "
>    XmbLookupString gives 1 bytes: (20) " "
>    XFilterEvent returns: False
>
> KeyRelease event, serial 36, synthetic NO, window 0x4400001,
>    root 0x1a7, subw 0x0, time 4886517, (45,174), root:(1474,224),
>    state 0x10, keycode 65 (keysym 0x20, space), same_screen YES,
>    XLookupString gives 1 bytes: (20) " "
>    XFilterEvent returns: False
>
> --
> Can't use space bar in search bar when using french alternative keyboard
> https://bugs.launchpad.net/bugs/221112
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Philippe (pcreux)]

Again: Things are working for me using "France Alternative" layout.

φ

On Wed, Nov 4, 2009 at 11:36, Philippe Creux <email address hidden> wrote:
> Same output as Creak.
>
> φ
>
>
>
> On Wed, Nov 4, 2009 at 11:12, Creak <email address hidden> wrote:
>> I don't know what your fix is, but it seems to work, here is my output:
>>
>> // pressing left Ctrl
>>
>> KeyPress event, serial 36, synthetic NO, window 0x4400001,
>>    root 0x1a7, subw 0x0, time 4885397, (45,174), root:(1474,224),
>>    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
>>    XLookupString gives 0 bytes:
>>    XmbLookupString gives 0 bytes:
>>    XFilterEvent returns: False
>>
>> // pressing space
>>
>> KeyPress event, serial 36, synthetic NO, window 0x4400001,
>>    root 0x1a7, subw 0x0, time 4885613, (45,174), root:(1474,224),
>>    state 0x14, keycode 65 (keysym 0x20, space), same_screen YES,
>>    XLookupString gives 1 bytes: (00) ""
>>    XmbLookupString gives 1 bytes: (00) ""
>>    XFilterEvent returns: False
>>
>> // releasing space
>>
>> KeyRelease event, serial 36, synthetic NO, window 0x4400001,
>>    root 0x1a7, subw 0x0, time 4885732, (45,174), root:(1474,224),
>>    state 0x14, keycode 65 (keysym 0x20, space), same_screen YES,
>>    XLookupString gives 1 bytes: (00) ""
>>    XFilterEvent returns: False
>>
>> // releasing control
>>
>> KeyRelease event, serial 36, synthetic NO, window 0x4400001,
>>    root 0x1a7, subw 0x0, time 4885877, (45,174), root:(1474,224),
>>    state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
>>    XLookupString gives 0 bytes:
>>    XFilterEvent returns: False
>>
>> ------------------ pressing only space : ------------------
>>
>> KeyPress event, serial 36, synthetic NO, window 0x4400001,
>>    root 0x1a7, subw 0x0, time 4886421, (45,174), root:(1474,224),
>>    state 0x10, keycode 65 (keysym 0x20, space), same_screen YES,
>>    XLookupString gives 1 bytes: (20) " "
>>    XmbLookupString gives 1 bytes: (20) " "
>>    XFilterEvent returns: False
>>
>> KeyRelease event, serial 36, synthetic NO, window 0x4400001,
>>    root 0x1a7, subw 0x0, time 4886517, (45,174), root:(1474,224),
>>    state 0x10, keycode 65 (keysym 0x20, space), same_screen YES,
>>    XLookupString gives 1 bytes: (20) " "
>>    XFilterEvent returns: False
>>
>> --
>> Can't use space bar in search bar when using french alternative keyboard
>> https://bugs.launchpad.net/bugs/221112
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>

[Creak (romain-failliot)]

Same as Philippe. I forgot to mention that this is the output when the search in Rhythmbox works.
Here is the result if I switch back to the default option (but still using "French Alternative" layout). So that Rhythmbox's search doesn't work anymore and, as you can see, the space in Ctrl+Space is a space:

// pressing left Ctrl

KeyPress event, serial 36, synthetic NO, window 0x4400001,
    root 0x1a7, subw 0x0, time 19372022, (18,174), root:(1402,642),
    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

// pressing space

KeyPress event, serial 36, synthetic NO, window 0x4400001,
    root 0x1a7, subw 0x0, time 19372214, (18,174), root:(1402,642),
    state 0x14, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XmbLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

// releasing space

KeyRelease event, serial 36, synthetic NO, window 0x4400001,
    root 0x1a7, subw 0x0, time 19372358, (18,174), root:(1402,642),
    state 0x14, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

// releasing control

KeyRelease event, serial 36, synthetic NO, window 0x4400001,
    root 0x1a7, subw 0x0, time 19372694, (18,174), root:(1402,642),
    state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

------------------ pressing only space : ------------------

KeyPress event, serial 36, synthetic NO, window 0x4400001,
    root 0x1a7, subw 0x0, time 19368942, (18,174), root:(1402,642),
    state 0x10, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XmbLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x4400001,
    root 0x1a7, subw 0x0, time 19369046, (18,174), root:(1402,642),
    state 0x10, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

So to sum up:
If you select the keyboard layout option to send a regular space (the workaround case), Ctrl+Space send a "00" event.
If you select the default keyboard layout option (the bug case), Ctrl+Space send a "20" event.

[Camille Appert (bibinou)]

Thanks for providing support, a reboot finally did the trick.

Thanks for nailing this :

> So to sum up:
> If you select the keyboard layout option to send a regular space (the workaround case), Ctrl+Space send a "00" event.
> If you select the default keyboard layout option (the bug case), Ctrl+Space send a "20" event.
>

[Creak (romain-failliot)]

As I could see in the google bugtracker: http://code.google.com/p/quodlibet/issues/detail?id=300
It also affect the chinese people... Is it big enough?

[fred0202002 (fred0202002)]

It s OK that's work with the "france legacy alternative" keybord
Thank you for all.

[Mathieu Comandon (strycore)]

Of course it affects the Music Store in Rhythmbox too.

[Jim Braux-Zin (j-brauxzin)]

Yes, impossible to look for "marina and the diamonds" for example, either in the search bar or in the new Ubuntu Music Store. I can understand that the problem can be hard to fix though it is only one radiobox to check by default in the layout options (see answer 41 by Christophe Mehay)... But really no one can say that not being able to write spaces in a search box is a huge usabilty issue. Just imagine what a (French) newcomer to Ubuntu would think!

And by the way I don't know what those unbreakable spaces are for, I have never noticed them so I don't think anyone would miss them.

Another simple fix is to use Banshee. I ran into this issue on my Lucid netbook when I wanted to check the new Music Store and to see how Rhythmbox had evolved, I am more than disappointed and it is not even Rhythmbox fault, what a shame.

[alexduf (dufournetalexandre)]

OK, in ubuntu 10.04 beta, the bug was here using default options.
Just check the option "Utiliser la barre d'espacement pour insérer un éspace insécable" to "la barre d'espacement renvoie une espace ordinaire à tous les niveaux"

Now rythmbox can be used, and i can search what i want on the music store.
But it's pretty tricky, maybe this kind of things could be in the "100 paper cuts" next time ?

[Creak (romain-failliot)]

I already tried to send it to 100 paper cuts (https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/221112/comments/59) but it has been refused (https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/221112/comments/61)...

I think it's not normal that this bug is here for more than two years. Actually I don't care who's wrong in this situation, if it's xorg or rhythmbox or whatever. I just want it to be solved.

[Jim Braux-Zin (j-brauxzin)]

Come on, this is a *huge* usability issue affecting almost all French users and which can be fixed by changing a single default option. I can't see how anything could be more suitable for a "paper cut"!

[beytu (beytu)]

Hi,

it's also affect the ubuntu one music store in the last beta 2 of 10.04. In this case, i can't look for "bob marley". Every time i tried to insert the space character, the music switch from pause to play and "vice versa"

.

[Creak (romain-failliot)]

I want to precise that I'd be glad to do the modification myself (like changing the shortcut), but after having been refused several times for other modifications in Rythmbox, I've lost my motivation.

[Didier Roche-Tolomelli (didrocks)]

Sorry to reopen this one again, but no solution was found with upstream and some applications like rhythmbox and totem use Ctrl + space as accelerators which seems to be looked up by gtk_action_group_add_toggle_action. As Ctrl + space and space in this layout returns the same XLookupString (see above), we can't use space on those applications. This is particularly frustrating in the search field, for instance :)
(you can have a look at https://bugs.edge.launchpad.net/ubuntu/+source/rhythmbox/+bug/221112?comments=all already referenced in the thread)

I tried to read a whole bunch of documentation regarding what leads to the current chosen solution in oss (the "include level4nl") and talked to svu too.
So, the fix was from https://bugs.freedesktop.org/show_bug.cgi?id=9529#c29.

I still don't understand how the level5 applied to Right Ctrl and "clever" management of the modifier (LOCAL_EIGHT_LEVEL) impacts the left Ctrl key. Input there will be appreciated :)

So, the "bug" is workarounded if I include level4n for to replace level4nl. The XLookupString is no more the same. Apparently, there will be no more level 5 modifier (which is right ctrl, right?). Is it really useful? If I include "level5(rctrl_switch)", we will be back in what the fix was intented: no more rctrl working in some apps like virtualbox (I hope I'm right there).

So, here is the result of my research, do not hesitate to correct me if I'm wrong anywhere. What do you think about changing this (I can distro patch if needed) in Ubuntu switching include level4nl to include level4n and no more adding a 5th level?
(not sure what use the 5th level). Unbreakable space is still reachable by Altgr + v.

So, getting feedback on someone more technically involved would be great, thanks in advance!

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

To sum up

1. French language uses three forms of spaces (normal space, no-break space, short no-break space), as defined in official typographic rules
2. The natural key people expect to output those spaces is the spacebar
3. They can not be put on the first levels because experience shows too many users do not depress shift before the spacebar and generate nobreakspaces accidentally if shift/caps is used as modifier
4. The iso-defined key to access other levels is ctrlgr (right ctrl, see canadian multinational keyboard)

So there is *no* good alternative to use ctrlgr + spacebar to emit those symbols

IIRC xkb has problems distinguishing right ctrl and left ctrl. So you can try to open a bug on this problem so left ctrl + space does not trigger the fifth level.

But right-crtl+space won't be given to apps. If apps expect to grab it, apps are wrong.

[Didier Roche-Tolomelli (didrocks)]

ok, after discussing with upstream, try to find where the issue can be fixed in a elegant manner, it seems we can find a workaround in xkeyboard-config (but loosing the right ctrl key modifier, this is a tradeoff). Reassigning the package for that.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xkeyboard-config - 1.8-1ubuntu7

---------------
xkeyboard-config (1.8-1ubuntu7) lucid; urgency=low

  * add debian/patches/130_fix_oss_ctrl_space_accelerator.patch:
    - don't include level4nl but only level4n for french oss layout.
      both space and Ctrl + space returned the same XLookupString, which
      prevents space using in some application using
      gtk_action_group_add_toggle_actions to setup Ctrl + space accelerator.
      We loose rctrl accelator but that's better than not having space in
      those applications. Setup it manually will reintroduce
      https://bugs.launchpad.net/bugs/198759 (LP: #221112)
 -- Didier Roche <email address hidden> Wed, 14 Apr 2010 18:15:30 +0200

[Creak (romain-failliot)]

First of all, thanks a lot Didier for handling this bug!
And second of all ^^, what do you mean by "loosing the right ctrl key modifier"? Do you mean it just won't work anymore? If that's the case, could you explain us why (I don't see the link between the ctrl key and the space bar)

Thanks!

[Didier Roche-Tolomelli (didrocks)]

Well, it's quite complicated and took me one full day to talk to upstream, look at the involved code, and so on…
You can have a look at the source upload or upstream bug, but in a nutshell:
- we don't use loose right control key in the oss layout :)
- we just loose the modifier combo like "right control" + a letter (or any other key).

This is less used than space in rhythmbox or totem. So the choice made was that one. I recommend you to see upstream bug as well as the one listed in the changelog (#198759), all duplicates, and the upstream one of #198759 to get the whole map.

This explains why the bug wasn't fixed for so long.

[Didier Roche-Tolomelli (didrocks)]

Please do not change the status without any comment. I can still use the space bar here on maverick today's update with french alternative oss keyboard.

[BobMauchin (zebob.m)]

This bug has been bothering me again.

Instead of
    include "nbsp(level4nl)"
I used:
    include "nbsp(level4n)"
    include "level5(rctrl_switch)"

With these parameters, Rhythmbox search is working correctly and we do have the thin nbsp on the sixth level (RCtrl+Shift+Space) as needed by Nicolas Mailhot.

Is this okay for you?

[Sergey V. Udaltsov (svu)]

Lads, for me that makes no difference. Just please settle that between you

[Laurent Dinclaux (dreadlox)]

Bug is still there in natty

[Creak (romain-failliot)]

Reminder: the workaround is to use the "France" keyboard layout instead of "France Autre"

[Milan Bouchet-Valat (nalimilan)]

Could you make a choice at last? This bug is very annoying, and since the solution is here, please decide fast about it. Thanks! ;-)

[Sergey V. Udaltsov (svu)]

I am ok with solution by zebob. Any objections? Nicolas?

[Milan Bouchet-Valat (nalimilan)]

Ping! ;-)

Sergey, can you commit any solution? Better get a fix than wait for ages to be sure it's the best choice.

[Sergey V. Udaltsov (svu)]

Ok, committed that one. Please check.

[Valentin Crone (va-crone)]

I'm affected by this bug on Ubuntu 12.04 LTS (amd64) with French → French Keyboard.
When I enter a search, if I press the spacebar, the letter doesn"t appear but the play/pause button is actionned.

[Brian Murray (brian-murray)]

Hello Creak, or anyone else affected,

Accepted xkeyboard-config into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Creak (romain-failliot)]

Thanks for the fix!

I'm sorry I can't test this package, I'm no longer on Ubuntu.
I'm sure someone else can test it though considering the number of users registered to this bug and to its duplicates.

[Sebastien Bacher (seb128)]

I can confirm that the update fixes the issue

[Emmanuel Castro (emmanuel-castro)]

The solution posted in comment #27 disables the standard behaviour of the Right-Ctrl key. It is annoying for most users! (I first thought that my keyboard was broken).

See the bug 1013881 in Ubuntu
https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/1013881

My opinion is that the right solution to solve the RhythmBox bug is to remove the line
  include "nbsp(level4nl)"
not patching the keyboard with the ugly
  include "level5(rctrl_switch)"

Maybe we can solve the nbsp handling as it is the problem.

Which language has a successful keyboard that handles nbsp?

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

(In reply to comment #33)
> The solution posted in comment #27 disables the standard behaviour of the
> Right-Ctrl key. It is annoying for most users! (I first thought that my
> keyboard was broken).
>
> See the bug 1013881 in Ubuntu
> https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/1013881
>
> My opinion is that the right solution to solve the RhythmBox bug is to remove
> the line
> include "nbsp(level4nl)"
> not patching the keyboard with the ugly
> include "level5(rctrl_switch)"
>
> Maybe we can solve the nbsp handling as it is the problem.
>
> Which language has a successful keyboard that handles nbsp?

right ctrl is the standard access key for level 5+6 (just like right alt is for levels 3-4 and yes you'll find keyboards where right alt is the same as left alt and not alt gr)

See for example this:
https://upload.wikimedia.org/wikipedia/commons/d/d0/KB_Canadian_Multilingual_Standard_comment-en.svg

So you can not remove right ctrl use without lowering the layout level number, and if you do so people start emitting nbsp my mistake (that was the biggest source of complain for one of this layout ancestors)

[Emmanuel Castro (emmanuel-castro)]

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)"

[Emmanuel Castro (emmanuel-castro)]

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.

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

(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

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

(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)]

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.

[Creak (romain-failliot)]

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.

[Emmanuel Castro (emmanuel-castro)]

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)

[Guillaume Martres (smarter)]

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

[Sergey V. Udaltsov (svu)]

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

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

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

[Sergey V. Udaltsov (svu)]

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;)

[Wettstein509 (wettstein509)]

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.

[Sergey V. Udaltsov (svu)]

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

[Guillaume Martres (smarter)]

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

[Samuel thibault (samuel-thibault)]

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

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

(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

[Colomban Wendling (banw)]

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

[Remi (remi)]

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.

[Swâmi Petaramesh (swami-petaramesh)]

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.

[Dominique Meeùs (dominiquem)]

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.

[Sergey V. Udaltsov (svu)]

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

[Colomban Wendling (banw)]

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

[Sergey V. Udaltsov (svu)]

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

[Swâmi Petaramesh (swami-petaramesh)]

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

[Creak (romain-failliot)]

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?

[Sergey V. Udaltsov (svu)]

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.

[Swâmi Petaramesh (swami-petaramesh)]

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.

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

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

[Swâmi Petaramesh (swami-petaramesh)]

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.

[Aurélien Bompard (abompard)]

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.

[Swâmi Petaramesh (swami-petaramesh)]

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.

[Sergey V. Udaltsov (svu)]

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.

[Olivier Grégoire (ogregoire)]

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

[Swâmi Petaramesh (swami-petaramesh)]

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 ?

[Swâmi Petaramesh (swami-petaramesh)]

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.

[Dominique Meeùs (dominiquem)]

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.

[Remi (remi)]

(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)]

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)]

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 ;)

[Swâmi Petaramesh (swami-petaramesh)]

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

[Sergey V. Udaltsov (svu)]

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

Regarding the voting, is there generic popular Linux-oriented site in France? Like slashdot.org or smth...

[Yvon TANGUY (vono22)]

At my knowledge it is http://linuxfr.org/ the most famous and oldest site of that kind.
There is also others web sites, but they are more general, they have general computer related news (http://www.nextinpact.com/ http://www.clubic.com/ http://www.numerama.com/).

[Nounours (mickael-corniere)]

There is also ubuntu-fr.org
Le 27 avr. 2014 00:01, "Yvon TANGUY" <email address hidden> a écrit :

> At my knowledge it is http://linuxfr.org/ the most famous and oldest site
> of that kind.
> There is also others web sites, but they are more general, they have
> general computer related news (http://www.nextinpact.com/
> http://www.clubic.com/ http://www.numerama.com/).
>
> --
> 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 (space
> is the shortcut for playing/pausing the song). I've just installed the last
> Hardy release candidate.
>
> Problem...

[Thomas Detoux (detoux)]

2014-04-26 16:50 GMT-04:00 Sergey V. Udaltsov <email address hidden>:

> Regarding the voting, is there generic popular Linux-oriented site in
> France? Like slashdot.org or smth...
>

I think you are looking for http://linuxfr.org/

[Swâmi Petaramesh (swami-petaramesh)]

Okay, your "vote" is currently happening on

https://bugs.launchpad.net/bugs/1013881

with 4 new entries today (from different people), 100% of them saying :

« PLEASE GIVE US OUR RIGHT [CTRL] KEY BEHAVING AS A [CTRL] KEY BACK !!! »

To summarize further, AFAIK, there is ONE person in the world happy that the french right [CTRL] has been broke, 100% of the other french keyboard users who want their [CTRL] key back,...

...and the rest of the world doesn't use a french keyboard and doesn't care.

[Sergey V. Udaltsov (svu)]

Nicolas, I understand the logic in your position about Level 5. But I see a number of unhappy people. Could we find some other level5 chooser?

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

(In reply to comment #66)

> Regarding the voting, is there generic popular Linux-oriented site in
> France? Like slashdot.org or smth...

There is a popular Linux-oriented site in France (linuxfr.org) and the final ajustments of this layout were done after discussion on this site.

I realise there is a vocal minority that does not like some of those choices but
1. the other alternatives used in the ancestors of this layout generated a lot more hate mail
2. because I knew there was no choice everyone would like spacebar layout is modular (and I'm the person who modularized it as part of the creation of this layout). People can choose the previous behaviour if they want and a few other possibilities were added as part of the modularization
3. so far no one proposed any better option appart from removing symbols which are necessary to write proper French (arguably proper French is not the same as C code). It's a lot easier to clamor for removal of the bits you do not use than to try to design a general-purpose solution without cutting corners

[Dominique Meeùs (dominiquem)]

(In reply to comment #69)
…
> > Regarding the voting, is there generic popular Linux-oriented site in
> > France? Like slashdot.org or smth...
>
> There is a popular Linux-oriented site in France (linuxfr.org) and the
> final ajustments of this layout were done after discussion on this site.
>
> I realise there is a vocal minority that does not like some of those choices

A site like linuxfr.org may well be a vocal minority in itself. Nothing proves that linuxfr.org is representative of ordinary users. And even on linuxfr.org I have seen posts saying "where is my CRTL-R gone?" or "my keyboard is broken since some new version of Ubuntu".
In a way, suppressing one of the customary CTRL keys is intrinsically a minority point of view.
[Furthermore, the French layout for the Belgian keyboard depends on the French layout for the French keyboard. I do not see why a discussion on linuxfr.org should decide that Belgians have no use of right CTRL.]

> but
> 1. the other alternatives used in the ancestors of this layout generated a
> lot more hate mail

I doubt having a right CTRL key ever generated hate mail. That hate mail was about other questions.

> 2. because I knew there was no choice everyone would like spacebar layout is
> modular (and I'm the person who modularized it as part of the creation of
> this layout). People can choose the previous behaviour if they want and a
> few other possibilities were added as part of the modularization

We are not here discussing space bar, but right CTRL. Is right CTRL modular? Is there an option easily accessible to the ordinary user to restore right CTRL?

> 3. so far no one proposed any better option appart from removing symbols
> which are necessary to write proper French (arguably proper French is not
> the same as C code). It's a lot easier to clamor for removal of the bits you
> do not use than to try to design a general-purpose solution without cutting
> corners

The clamor is not against proper French of for removal of anything. Furthermore, how could an ordinary user "try to design a solution"? The user wants a common PC keyboard with CTRL keys, without having to write the code himself. The clamor is: do what you can to allow writing proper French —and thank you for your trying to do it— but leave the right CTRL.
-------
If no agreement can be reached, would it be possible to have the old layout accessible, even under another name? I do not know how many variants are allowed, by design, or by freedesktop conventions. Of course a new variant would be useless if it didn’t appear in the choices offered to an ordinary user by the most popular GNU Linux distributions.

[Colomban Wendling (banw)]

(In reply to comment #69)
> (In reply to comment #66)
>
> > Regarding the voting, is there generic popular Linux-oriented site in
> > France? Like slashdot.org or smth...
>
> There is a popular Linux-oriented site in France (linuxfr.org) and the
> final ajustments of this layout were done after discussion on this site.

But this has the same pitfall as any volunteered survey, it isn't any kind of representative. I for example myself barely ever read a linuxfr article, and wouldn't participate or even see a survey there. That doesn't mean I'm not a French fr/oss user :)

Also note that people suffering from the situations are a lot more likely to do something and speak their mind than people perfectly happy with the situation. So probably "discussing" a problem is likely to only include opinion from people not happy with the current state, and people closely involved.

> I realise there is a vocal minority that does not like some of those choices
> but

Just to be fair, I see *no one* else here arguing towards keeping right Ctrl Level5 modifier -- but sure, as I state above, people happy with it won't see the discussion or care, so it may be biased.

> 1. the other alternatives used in the ancestors of this layout generated a
> lot more hate mail

If it broke people's apps (or apps broke with it, I don't care who's fault it is), I surely can understand people being angry. But similarly, since the change from this report broke people's right Ctrl key, I can understand they get angry.

> 2. because I knew there was no choice everyone would like spacebar layout is
> modular (and I'm the person who modularized it as part of the creation of
> this layout). People can choose the previous behaviour if they want and a
> few other possibilities were added as part of the modularization

And we thank you for your work. But I don't think it's realistic to think everyone can "choose the previous behavior" if it means editing the keymap. I already said it, but it took me quite some time to find what caused my right Ctrl key to no longer work and fix it, and I think it's fair to consider myself a quite advanced user.

If really reverting the addition of Level5 is not an option (but see below), please add an alternative layout.

> 3. so far no one proposed any better option appart from removing symbols
> which are necessary to write proper French (arguably proper French is not
> the same as C code).

The change in this particular report did not add or remove any symbol, it only moved one to Level5 because some apps couldn't handle <Ctrl>Space with this layout. And as I said earlier, most of the incriminated apps (at least that I know of) don't even use <Ctrl>Space anymore, rendering the change moot for them.

And even if we wanted to please those apps, we mayb be able to without adding a new modifier (Level5) and a key for it -- again, see (comment #46).

Also note that event though I admittedly don't use short-nbsp (I'm afraid I don't know the rules where this one should be used in French typography), I'm an heavy user of nbsp everywhere French typography tells me to do it. So no, I don't want to remove anything, don't worry -- but I'd like my rig...

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

(In reply to comment #70)

> If no agreement can be reached, would it be possible to have the old layout
> accessible, even under another name?

The old layout was never removed and kept its historical name (fr latin9)

[Colomban Wendling (banw)]

(In reply to comment #72)
> The old layout was never removed and kept its historical name (fr latin9)

No, we are speaking here of fr/oss, but before it got right Ctrl as level5 modifier (what this bug end up changing).

I bet everyone complaining here was very happy with fr/oss before this Level5 modifier -- at least I was, this map has so everything useful (and more) on handy locations :)

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

(In reply to comment #71)

> And even if we wanted to please those apps, we mayb be able to without
> adding a new modifier (Level5) and a key for it -- again, see (comment #46).

I'm pretty sure some of the other spacebar configurations available as xkb options do not require level5. They are not the default for fr(oss) because without level5 it is too easy to type a nbspc by mistake and random nbspc everywhere breaks lots of things (as reported by fr latin9 users).

[Remi (remi)]

Nicolas,

Where does the need to *have* a key for nbsp come from? Isn't a compose combo more appropriate and less error-prone?

Cheers

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

(In reply to comment #75)
> Nicolas,
>
> Where does the need to *have* a key for nbsp come from?

Because unlike in English most French punctuation symbols require a space (sometimes a short space) before. And if it's not a non-breakable space apps will perform line breaks at the wrong position and you'll end up with orphan sumbols at line starts

Online
http://fr.wikipedia.org/wiki/Espace_ins%C3%A9cable

Actual authoritative reverence (highly recommended if you want to work on any system with French inputs or outputs)
http://www.amazon.fr/Lexique-r%C3%A8gles-typographiques-lImprimerie-Nationale/dp/2743304820

Lack of non breakspace on French layouts on some OSes is such a basic problem OpenOffice/LibreOffice had to hardcode a nbspc combo but that does not help when writing in you MUA, your browser, your IM client, etc

> Isn't a compose
> combo more appropriate and less error-prone?

Compose is not appropriate for basic symbols you need to write pretty much any correct sentence in the target language. And adding a specific input method for one symbol just because some people can't live with the modifier ISO chose for level 5 is disproportionnate.

[Colomban Wendling (banw)]

(In reply to comment #76)
> Compose is not appropriate for basic symbols you need to write pretty much
> any correct sentence in the target language. And adding a specific input
> method for one symbol just because some people can't live with the modifier
> ISO chose for level 5 is disproportionnate.

Woow, calm down guys. What's disproportionate is the reaction here! *before* the change this report introduced, and which many of us are trying to get reverted, *both* nbsp and nbspc were easily available:

nbsp AltGr+Shift+Space
nbspc Ctrl+Shift+Space

Reverting the change this report introduced would get this behavior. Please understand we just want to get nbspc moved back where it *was* (or for me, anywhere on a 1-4 level), not removed or anything. Also, realize that currently there is only *one* Level5-specific symbol, and that's nbspc, so we basically have a key only for that.

[Remi (remi)]

I'm at a loss as to what to do to help find a solution for everyone.

fr-oss is a great layout with many useful improvements over fr-latin9, but the missing ControlR is a deal breaker. I'm personally back to using the default "fr" layout and I'll advise users to do the same if they want their ControlR back.

@Ubuntu users listening in through Launchpad: use whatever control panel you have to select a layout that doesn't have the words "Alternative" or "variante".

Cheers

[Wettstae (wettstae)]

Created attachment 98826
Make Level 5 choosers more easily available

The patch makes existing options for Level 5 choosers more easily available by adding them to the rules. This is useful in its own right, irrespective of this bug. In context of this ongoing discussion, it would allow to change back to the old default, and allow users who prefer the current behaviour to use the options lv5:rctrl_switch and nbsp:level4n to get their preferred behaviour.

[Swâmi Petaramesh (swami-petaramesh)]

About a "short nbsp" in french, let's make it perfectly clear that there must be about a hundred professionnal typographists in the whole country who care about it - most of them not using Linux BTW - and the rest of the ~40 million computer users here don't give a shit about a "short nbsp" and don't even know what it is, feel perfectly happy with the "correct french" they write without it, and many of them just would like their fscking right [Ctrl] key back.

If a so thin minority of professional typographists that in no way represent the average french "Joe" user want this modifier, it's perfectly OK that they devise their own special layout for their on needs, but by no means impose it on the rest of us.

[Swâmi Petaramesh (swami-petaramesh)]

BTW, about the punctuation signs that, in French, requires a nbsp before them, i.e. " ; : ! ? " (for perfect typographic correctness, while usually few people know about this and nobody really cares...) :

Usual word processing programs, such as OpenOffice / LibreOffice, when configured to the french locale, add these typographically required nbsps automagically, so people actually do not have to type the nbsp, which makes the need for an easy entry of these still less of an issue.

Should we follow the slope of stealing a useful right [Ctrl] key for this, then me might well in the future steal the left one for the dash " - ", as in french, we typographically use at least 3 different lenghts for dashes. As previously, word processing software usually transforms the "normal dash" into the "typographically correct dash"... Nope, all this mess of quite complex and unusual characters is the very reason for which meta and compose keys exist in the first place...

[Remi (remi)]

Swâmi,

We've all laid out these arguments many times over. Yes, this issue is frustrating (and I regret having vented some of my own frustration in my first comments) but let's keep it civil.

There are proposed solutions. I, for one, think Andreas' proposal is the best way out of the current dead lock as it would allow each and everyone of us to configure the fr-oss layout the way we want it. It's now up to Sergey and Nicolas to decide how to move this forward.

Cheers

[Samuel thibault (samuel-thibault)]

I too believe that Andreas' proposal is the right one. It permits people who really want the extra 5th level to be able to easily get it, while not breaking the 99% usual usage.

Just for the record, I had not seen the linuxfr discussion. I guess mostly only people who would want the extra 5th level did realize that it would steal the right control key. If a discussion happened on "are people fine with making the right control key the 5th level modifier by *default*", the result would be quite different, I believe.

[Daniel Stone (daniels)]

At the risk of just making things worse ...

My €0.02 is that we should stick with level 5 right Control as being optional. This is a marginal (in terms of percentage of userbase that will ever see/use it) layout that people have to go out of their way to use, but still taking away a modifier is a pretty big and surprising step.

I've got sympathy with the non-breaking-space thing from a strict technical correctness point of view, however it just can't be essential for day-to-day usage if Windows requires you to enter it by the Unicode codepoint. If such a large percentage of the French-speaking world cope with it, then so can we.

I think Andreas's proposal is the only sensible one. Some people won't be happy with it, but if this discussion (and that of Bépo) has shown us anything, it's that you really can't please anyone when dealing with alternate French keyboard layouts.

[Julien Cristau (jcristau)]

FWIW after user complaints I've reverted this change in Debian's xkeyboard-config, to have right control behave normally again.

[Sergey V. Udaltsov (svu)]

ok, Daniel and Julien put last two nails into that coffin. I removed right control as level5 modifier in git. Thank you everybody. Really sorry there is no perfect solution here...

[Julien Cristau (jcristau)]

the fix looks like it'll reintroduce some form of #9529? or was the use of level4n instead of level4nl intentional?

[Steve Langasek (vorlon)]

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release