registry team mailing list archive
-
registry team
-
Mailing list archive
-
Message #14461
[Bug 221112] Re: Can't use space bar in search bar when using french alternative keyboard
Launchpad has imported 27 comments from the remote bug at
http://bugs.freedesktop.org/show_bug.cgi?id=15804.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2008-05-02T11:31:59+00:00 Ludovic Lebègue wrote:
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"
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/16
------------------------------------------------------------------------
On 2008-05-02T11:32:46+00:00 Ludovic Lebègue wrote:
Created an attachment (id=16310)
xorg.conf
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/17
------------------------------------------------------------------------
On 2008-05-02T13:32:00+00:00 Sergey V. Udaltsov wrote:
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.
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/22
------------------------------------------------------------------------
On 2008-05-02T14:19:32+00:00 Ludovic Lebègue wrote:
>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 ?
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/23
------------------------------------------------------------------------
On 2008-05-02T14:23:37+00:00 Ludovic Lebègue wrote:
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")
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/24
------------------------------------------------------------------------
On 2008-05-02T15:35:40+00:00 Sergey V. Udaltsov wrote:
This is actually distro-specific, xkeyboard-config has nothing to do
with it. FWIW fr(oss) produces space when space is pressed.
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/25
------------------------------------------------------------------------
On 2008-05-02T15:43:18+00:00 Ludovic Lebègue wrote:
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 ?
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/26
------------------------------------------------------------------------
On 2008-05-02T15:51:01+00:00 Sergey V. Udaltsov wrote:
You can easily check. Try running xev utility and press space
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/27
------------------------------------------------------------------------
On 2008-05-02T17:23:47+00:00 Ludovic Lebègue wrote:
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.
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/28
------------------------------------------------------------------------
On 2008-05-02T17:53:13+00:00 Sergey V. Udaltsov wrote:
> 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.
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/29
------------------------------------------------------------------------
On 2008-05-03T00:21:47+00:00 Ludovic Lebègue wrote:
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 ?
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/31
------------------------------------------------------------------------
On 2008-05-03T01:00:11+00:00 Ludovic Lebègue wrote:
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
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/32
------------------------------------------------------------------------
On 2008-05-03T05:38:12+00:00 Sergey V. Udaltsov wrote:
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.
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/33
------------------------------------------------------------------------
On 2008-05-03T14:18:45+00:00 Ludovic Lebègue wrote:
For reference here is the bug to GNOME
http://bugzilla.gnome.org/show_bug.cgi?id=531279
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/38
------------------------------------------------------------------------
On 2008-05-26T13:57:25+00:00 Ludovic Lebègue wrote:
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
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/44
------------------------------------------------------------------------
On 2008-05-27T06:38:12+00:00 Sergey V. Udaltsov wrote:
> Does that help ?
Do you ask me? Since you're reporter - it's up to you to make sure it
works for you;)
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/47
------------------------------------------------------------------------
On 2008-05-27T11:50:04+00:00 Ludovic Lebègue wrote:
>From the user point of view (this is mine) it helps indeed.
Can this help to find a solution ?
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/48
------------------------------------------------------------------------
On 2008-05-27T11:51:13+00:00 Ludovic Lebègue wrote:
I mean a solution suitable to everybody ... not only me :)
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/49
------------------------------------------------------------------------
On 2008-05-27T14:35:09+00:00 Sergey V. Udaltsov wrote:
Actually this nbsp(level4nl) was offered by Nicolas. I think it would be
good if you settle this issue (see bug #9529)
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/50
------------------------------------------------------------------------
On 2008-05-27T15:15:31+00:00 Nicolas-mailhot-laposte wrote:
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
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/51
------------------------------------------------------------------------
On 2008-05-27T15:25:13+00:00 Nicolas-mailhot-laposte wrote:
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.
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/52
------------------------------------------------------------------------
On 2008-05-27T22:58:30+00:00 Nicolas-mailhot-laposte wrote:
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
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/53
------------------------------------------------------------------------
On 2008-05-27T23:20:18+00:00 Ludovic Lebègue wrote:
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
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/54
------------------------------------------------------------------------
On 2008-05-28T08:22:17+00:00 Nicolas-mailhot-laposte wrote:
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.
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/55
------------------------------------------------------------------------
On 2008-05-28T08:59:47+00:00 Ludovic Lebègue wrote:
I'll try to do that. As for now I close this bug.
Thanks for your help.
Reply at: https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/56
------------------------------------------------------------------------
On 2010-04-13T12:00:18+00:00 Didier Roche wrote:
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!
Reply at:
https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/128
------------------------------------------------------------------------
On 2010-04-14T04:24:17+00:00 Nicolas-mailhot-laposte wrote:
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.
Reply at:
https://bugs.launchpad.net/libgnomekbd/+bug/221112/comments/129
** Changed in: xkeyboard-config
Status: Invalid => Confirmed
** Changed in: xkeyboard-config
Importance: Unknown => Medium
--
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 member of Registry
Administrators, which is the registrant for NULL Project.
