GDM: The Gnome Display Manager

Wrong keyboard settings when console-settings has multiple layouts

Reported by Psy[H[] on 2009-10-25
204
This bug affects 40 people
Affects Status Importance Assigned to Milestone
gdm
Expired
Medium
gnome-control-center
Fix Released
Medium
gnome-settings-daemon
Fix Released
Medium
console-setup (Ubuntu)
Undecided
Unassigned
Declined for Karmic by Sebastien Bacher
Lucid
Undecided
Unassigned
gdm (Ubuntu)
High
Martin Pitt
Declined for Karmic by Sebastien Bacher
Lucid
High
Martin Pitt
gnome-control-center (Ubuntu)
Medium
Martin Pitt
Declined for Karmic by Sebastien Bacher
Lucid
Medium
Martin Pitt
gnome-settings-daemon (Ubuntu)
High
Martin Pitt
Declined for Karmic by Sebastien Bacher
Lucid
High
Martin Pitt
xserver-xorg-input-evdev (Ubuntu)
High
Unassigned
Declined for Karmic by Sebastien Bacher
Lucid
High
Unassigned

Bug Description

Binary package hint: gnome-control-center

Situation:
two layouts - US (default), Ru (second)
Configuration was set up by sudo dpkg-reconfigure console-setup

Wrong behavior #1:
if I press "set defaults" in gnome-keyboard-properties, gconf keys are set to default values:
/desktop/gnome/peripherals/keyboard/kbd/layouts is [] empty - this is ok, because layouts are then taken from console-setup
Everything works until reboot or restart of gnome-settings-daemon:
/desktop/gnome/peripherals/keyboard/kbd/layouts is then set to [us] only! so it needs to be reconfigured every time.

Wrong behavior #1a:
if I press "set defaults", then
/desktop/gnome/peripherals/keyboard/general/defaultGroup is set to -1, but default layout radiobutton in g-k-p dialog is still visible as set, which is incorrect and confusing.

Wrong behavior #2:
If keyboard settings are set explicitly in gnome:
/desktop/gnome/peripherals/keyboard/kbd/layouts is set to [us ,ru]
then again everything works fine, but again only until reboot or restart of gnome-settings-daemon:
/desktop/gnome/peripherals/keyboard/kbd/layouts is set to [us ,ru,us] - second us layout appears out of nowhere.
It happens because first "us" is followed by tab symbol: " " so instead of [us,ru] it sets [us ,ru] and upon gnome-settings-daemon start the second, but correct "us" is added.

ProblemType: Bug
Architecture: i386
Date: Sun Oct 25 13:03:18 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: gnome-control-center 1:2.28.1-0ubuntu1
ProcEnviron:
 LANG=ru_RU.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: gnome-control-center
Uname: Linux 2.6.31-14-generic i686

Psy[H[] (vovik-wfa) wrote :
tags: added: gnome karmic keyboard
summary: - [karmic] Gnome keyboard properties conflicts with console-setup
+ Gnome keyboard properties conflicts with console-setup
affects: gnome-control-center (Ubuntu) → gnome-settings-daemon (Ubuntu)

hal/gdm don't really support the concept of multiple default layouts in /etc/default/console-setup, so having "set defaults" configure [us,ru] won't work.

But the additional "us" one is a bug. It seems that his original "us\t" value is the problem: it's a variant without a name. Can you please give the output of

  cat /etc/default/console-setup

?

Changed in gnome-settings-daemon (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
Psy[H[] (vovik-wfa) wrote :

Without commented lines:

VERBOSE_OUTPUT=no

ACTIVE_CONSOLES="/dev/tty[1-6]"

CHARMAP="UTF-8"

CODESET="CyrKoi"

FONTFACE="Fixed"
FONTSIZE="16"

XKBMODEL="pc105"
XKBLAYOUT="us,ru"
XKBVARIANT=","
XKBOPTIONS="grp:alt_shift_toggle,compose:ralt,grp_led:scroll"

> hal/gdm don't really support the concept of multiple default
> layouts in /etc/default/console-setup, so having "set defaults"
> configure [us,ru] won't work.

But shouldn't g-s-m leave layouts in gconf empty when key is set empty, instead of writing only [us]?

And what about gui bug in gnome-keyboard-properties (#1b) When dot is still visible even if default is not set?

Martin Pitt (pitti) wrote :

So, having multiple default layouts in console-setup conceptually does not make sense. hal should filter them out and just set the first one.

Changed in gnome-settings-daemon (Ubuntu):
status: Incomplete → Triaged
summary: - Gnome keyboard properties conflicts with console-setup
+ Wrong keyboard settings when console-settings has multiple layouts
affects: gnome-settings-daemon (Ubuntu) → hal (Ubuntu)
Changed in hal (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
Martin Pitt (pitti) wrote :

Ah, /usr/lib/hal/debian-setup-keyboard is shipped by xserver-xorg nowadays, will fix it there.

affects: hal (Ubuntu) → xorg (Ubuntu)
Martin Pitt (pitti) wrote :

Hm, before I declare the console-common task as valid, I first need to check whether "set system wide" button causes this.

Changed in console-setup (Ubuntu):
status: New → Invalid
Psy[H[] (vovik-wfa) wrote :

tab symbol appears only when changing layouts in gnome while /desktop/gnome/peripherals/keyboard/kbd/layouts is empty, i.e. changing them after "set defaults" is pressed. If gconf keys are correct, then #2 is no more. Isn't it just a gnome's problem?

To check "set system wide", I've added third layout - de, and pressed the button. /etc/default/console-setup was changed accordingly. Tab symbols are NOT being transferred to console-setup if they are in gconf. They also do not appear in gconf if they are not there previously.

But then another two things:
1. after /etc/default/console-setup is updated (de is added) there is no update in console itself - still us & ru there.
2. If I press "set defaults" after de is added to console-setup, then /desktop/gnome/peripherals/keyboard/kbd/layouts becomes empty, but there are only us & ru layouts left in g-k-p - why? there should be three of them according to console-setup!

Correct me if I'm wrong: the proper behavior should be:
When pressing "set defaults":
/desktop/gnome/peripherals/keyboard/general/defaultGroup shoud be set to 0 (instead of -1)
/desktop/gnome/peripherals/keyboard/kbd/layouts shoud be set to empty (and remain that way, until set explicitly)
so gnome have a default layout = first layout, and it does not override layouts from console-setup

Traumflug (mah-jump-ing) wrote :

Martin Pitt wrote:

> So, having multiple default layouts in console-setup conceptually does
> not make sense. hal should filter them out and just set the first one.

In case of Psy and me, this would pick up the wrong layout. "us" is the obsolete one, "ru" btw. "de" is the one printed to the caps of the keyboard.

Psy[H[] (vovik-wfa) wrote :

Traumflug, what do you mean?
Problem is - gnome leaves "defaultGroup" undefined (-1), but should set the first (0).
Also, if gconf "layouts" key is empty, gnome should not put anything there, until user decides to locally override global settings

Am 27.10.2009 um 14:01 schrieb Psy[[H[[]]:

> Traumflug, what do you mean?

I mean, if some software picks the first of two "default" layouts
[us,de], it'll pick the wrong one.

As Martin said already, having more than one "default" doesn't make
sense anyways.

Bryce Harrington (bryce) on 2009-10-30
Changed in xorg (Ubuntu):
status: Triaged → New
importance: Low → Undecided
Bryce Harrington (bryce) on 2009-10-30
affects: xorg (Ubuntu) → xserver-xorg-input-evdev (Ubuntu)
Martin Pitt (pitti) on 2009-11-04
Changed in xserver-xorg-input-evdev (Ubuntu):
status: New → Triaged
status: Triaged → In Progress
Jennie Petoumenou (jennie) wrote :

I am having the same problem with a clean installation of 9.10 in Greek.
I used the workaround mentioned here: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/401497/comments/20
(I think that bug #460328 and bug 401497 should be marked as duplicates).

For the record, here are some results from my installation:
Faulty setup:
grep X /etc/default/console-setup

# values as the XkbModel, XkbLayout, XkbVariant and XkbOptions options
# in /etc/X11/xorg.conf.
XKBMODEL="pc105"
XKBLAYOUT="us,gr"
XKBVARIANT=","
XKBOPTIONS="grp:alt_shift_toggle,lv3:ralt_switch"

gconftool-2 --get /desktop/gnome/peripherals/keyboard/kbd/layouts

[us\,gr \,]

Correct setup:
grep X /etc/default/console-setup

# values as the XkbModel, XkbLayout, XkbVariant and XkbOptions options
# in /etc/X11/xorg.conf.
XKBMODEL="pc105"
XKBLAYOUT="us,gr"
XKBVARIANT=","
XKBOPTIONS="grp:alt_shift_toggle,lv3:ralt_switch"

gconftool-2 --get /desktop/gnome/peripherals/keyboard/kbd/layouts

[]

Alkis Georgopoulos (alkisg) wrote :

Verifying this for Lucid Alpha 1.

Please make gdm use a [Default] layout by default, one which simply doesn't write anything to /desktop/gnome/peripherals/keyboard/kbd/layouts, as opposed to using/forcing the [us] layout.

Eric L. (ericl) wrote :

Hello,

I have a similar problem, but in my case it's the compose option which is ignored, in gdm, and in XFce4 and LXDE after (two different installations, same behavior).
I fix easily the problem by calling "setxkbmap -option compose:menu" but it's a pain in the bottom.

I attach a file showing all the information I could gather which I think might be relevant. A bugfix before the next Ubuntu release would be great...

Thanks, Eric

Sebastien Bacher (seb128) wrote :

the issue has been discussed on IRC, the multiple layouts is not a bug and required for non latin configurations which need to have both their layout and an us one to be able to type chars in the different alphabets they are using, gdm and GNOME should have the same layout list and allow switching between those

Changed in xserver-xorg-input-evdev (Ubuntu):
importance: Undecided → High
Changed in gnome-settings-daemon (Ubuntu Lucid):
importance: Undecided → High
importance: High → Undecided
assignee: nobody → Martin Pitt (pitti)
status: New → Confirmed
Changed in gdm (Ubuntu Lucid):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → High
status: New → Confirmed
Changed in gnome-settings-daemon (Ubuntu Lucid):
importance: Undecided → High
Sebastien Bacher (seb128) wrote :

bug #401497 and its duplicates could be the same issue

Paulus (donmatteo) wrote :

bug #283128, which includes a patch (!), might be the same issue as well.

tags: added: iso-testing
Martin Pitt (pitti) wrote :

xserver-xorg-input-evdev itself is fine, it just passes on the entire list to the udev property. So this is between gdm and g-s-d now, closing the -evdev task.

Changed in xserver-xorg-input-evdev (Ubuntu Lucid):
assignee: Martin Pitt (pitti) → nobody
status: In Progress → Invalid
Changed in gnome-settings-daemon (Ubuntu Lucid):
status: Confirmed → In Progress
Changed in gdm (Ubuntu Lucid):
status: Confirmed → In Progress
Martin Pitt (pitti) wrote :

I just tested current lucid with multiple layouts:

  [us,de,de\tnodeadkeys]

gdm is meant to pick precisely one keyboard layout (the one you want to use by default), so we should not and will not support lists in gdm. (This is what I originally meant with "multiple default layouts do not make sense"). So I close the gdm task.

What is actually wrong: If you pick a new layout in gdm (I chose "UK"), I get the correct layout added to gconf

  [us,de,de\tnodeadkeys,gb]

but it does not become the default layout. That is a g-s-d bug.

Changed in gdm (Ubuntu Lucid):
assignee: Martin Pitt (pitti) → nobody
status: In Progress → Invalid
Psy[H[] (vovik-wfa) wrote :

what about situation when there are two layouts in console setup (for example "us,ru") and gconf "layouts" key is empty?
g-s-d is being started - what will happen? Currently in karmic gconf "layouts" key becomes just [us]. Shouldn't it remain empty?

Martin Pitt (pitti) wrote :

Psy[H[] [2010-03-18 16:41 -0000]:
> what about situation when there are two layouts in console setup
> (for example "us,ru") and gconf "layouts" key is empty? g-s-d is
> being started - what will happen? Currently in karmic gconf
> "layouts" key becomes just [us]. Shouldn't it remain empty?

It should only be empty on your very first login. In this case I think
it should become [us,ru]. I know that this doesn't work right now,
that's part of the bug.

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Psy[H[] (vovik-wfa) wrote :

I may disagree. If "empty" = "no override", wouldn't it be logical to leave it empty and use system-level settings, until user decides to set something explicitly for himself?
In case of gdm, which is a system tool, not a user-owned profile, it is even more appropriate to follow system-level settings, but with possibility of optional gdm-level override.

another issue is /desktop/gnome/peripherals/keyboard/general/defaultGroup key.
Its default "-1" value (no defined default layout) is rather useless, it brings uncertainty in managing layouts when switching between several existing and new windows. "0" would be more appropriate.
But that isn't as important as the first issue.

Psy[H[] (vovik-wfa) wrote :

also if defaultGroup is set to "-1" then there should be no visible dot in gnome-keyboard-properties.

Martin Pitt (pitti) wrote :

Taking notes for myself, please ignore.

I tested this in more detail, and gsd always sets the current default layout to what is in $GDM_KEYBOARD_LAYOUT, so this is already working correctly.

Simple check which avoids logging out/in:

gconftool --type list --list-type string -s /desktop/gnome/peripherals/keyboard/kbd/layouts '[us,de]'
GDM_KEYBOARD_LAYOUT=gb gnome-settings-daemon --debug --no-daemon

-> I get "GBr" as default layout consistently, which is correct (g-s-d has code to match that).

So what we actually need now is one of those:

 - not override the system default if the user doesn't pick anything different in gdm; i. e. consider an empty list in gconf as a valid long-term configuration
 - passing the entire list of system defaults in $GDM_KEYBOARD_LAYOUT, with the one selected being first

The first seems easier to implement indeed.

Sorry for all the back and forth, it took me a while to test all the scenarios, read the code, and understand how things should work.

Changed in gnome-settings-daemon (Ubuntu Lucid):
assignee: Martin Pitt (pitti) → nobody
status: In Progress → Invalid
Changed in gdm (Ubuntu Lucid):
status: Invalid → In Progress
assignee: nobody → Martin Pitt (pitti)
Martin Pitt (pitti) wrote :

*sigh* seems we can't get around fixing it the complicated way of supporting lists in $GDM_KEYBOARD_LAYOUT. If the gconf key is empty, the keyboard layout indicator does not work, and for me g-s-d does not take the settings from udev.

Changed in gnome-settings-daemon (Ubuntu Lucid):
assignee: nobody → Martin Pitt (pitti)
status: Invalid → In Progress
Martin Pitt (pitti) wrote :

> /desktop/gnome/peripherals/keyboard/kbd/layouts is [] empty - this is ok, because layouts are then taken from console-setup
> Everything works until reboot or restart of gnome-settings-daemon:

How do you switch keyboard layouts then?

Martin Pitt (pitti) wrote :

OK, so how would this work:

 * We keep gdm as it is; gdm is responsible for picking _one_ layout which is the one used for entering the password, and the one which is active when you log into the session.

 * We fix g-s-d to read the system default layout(s) and add them to gconf

 * Afterwards we keep the current g-s-d behavior of evaluating $GDM_KEYBOARD_LAYOUT to see which of the available layouts should be selected.

As far as I can see, this will fix the original problem, avoid situations with empty gconf values which break the layout indicator and layout switching, and avoid intrusive patches and even more complex behaviour for $GDM_KEYBOARD_LAYOUT.

Alkis Georgopoulos (alkisg) wrote :

Before Karmic, I didn't have to configure gnome at all (meaning, all the gconf settings were working fine if they were empty).
Console-setup was configured to [us,gr], and X would pick it up and let me work with it, and allow me to switch layouts, no matter if I used an xterm, gnome, or kde session.
I could type a mixed English/Greek password in gdm.

I think it'd be better if all the involved programs were modified to work correctly when all the gconf keys are empty.
I.e. gconftool-2 --recursive-unset /desktop/gnome/peripherals/keyboard
inside a session should not result in a broken layout/ability to switch etc...

Psy[H[] (vovik-wfa) wrote :

Why make g-s-d add defaults from console-setup to gconf? Add nothing until user applies something that differs from console-setup settings. Let the layouts gconf key be empty until needed otherwise.

I'm proposing the following g-s-d behavior:
1. setting present in gconf = use it
2. setting is empty in gconf = use corresponding setting from console-setup without writing anything to gconf.
3. user applies setting that differs from console-setup setting = write it to gconf and follow rule #1.

Current wrong behavior in karmic: when gconf layouts key is empty, g-s-d adds "us" layout to it on its startup, despite I have "us,ru" in console-setup. So switching breaks.
fix variants:
1. Add settings correctly.
2. Leave layouts key as it is (empty), use console-setup settings directly
(latter is preferable).

Current wrong behavior in lucid:
When I press "set defaults" in g-k-p, all corresponding gconf-keys are being emptied. But console-setup settings are not being read. I have "us,ru" in console-setup, also "terminate:ctrl_alt_bksp" parameter. But none of this is being reflected in g-k-p.
When gconf layouts key is empty, g-s-d acts as if layouts key is set to "us". When g-s-d is restarted, it adds "us" to gconf key. So switching is broken in two ways.
fix variants:
1. Make "set defaults" button set correct default settings (from console-setup),
2. Make "set defaults" button set empty gconf keys, but correct g-s-d to use console-setup settings _directly_ when there is no override in gconf)
(latter is preferable).

Psy[H[] (vovik-wfa) wrote :

also a glitch in lucid:

when I set Xserver kill keys and layout switch keys through g-k-p, wrong syntax is being written to gconf key:

instead of writing:
[terminate:ctrl_alt_bksp,grp:alt_shift_toggle]
it writes:
[terminate terminate:ctrl_alt_bksp,grp grp:alt_shift_toggle]
(duplicated parameter name and tab symbol)

Psy[H[] (vovik-wfa) wrote :

after I manually correct all settings in gconf, "apply systemwide" button in g-k-p works fine: it asks for authorization and writes parameters from "layouts", "model" and "options" keys to console-setup.

summarizing problems:
1. g-s-d writes garbage to gconf (tab symbols, duplicated words > broken syntax) (karmic & lucid)
2. g-s-d does not read setting from console-setup when corresponding gconf keys is empty (lucid)
3. g-s-d haphazardly writes things to "layouts" key when it is empty, ignoring console-setup. (karmic & lucid)

Psy[H[] (vovik-wfa) wrote :

...I was wrong: "options" with dups and tabs are correctly translated to console-setup, being stripped of garbage. But why such distorted syntax in gconf?

Martin Pitt (pitti) wrote :

Psy[H[] [2010-03-22 21:35 -0000]:
> Why make g-s-d add defaults from console-setup to gconf? Add nothing
> until user applies something that differs from console-setup settings.

I think that should work as well, yes.

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Martin Pitt (pitti) wrote :

Psy[H[] [2010-03-22 22:26 -0000]:
> ...I was wrong: "options" with dups and tabs are correctly translated to
> console-setup, being stripped of garbage. But why such distorted syntax
> in gconf?

Does it actually work with that syntax? If not, can you please file a
separate bug about it, since it's a separate problem?

Thanks,

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Martin Pitt (pitti) on 2010-03-23
Changed in gdm (Ubuntu Lucid):
status: In Progress → Invalid
assignee: Martin Pitt (pitti) → nobody
Martin Pitt (pitti) wrote :

It gets fairly hilarious at this point to close/reopen gdm, I'm sorry. But we can't fix this properly in g-s-d without fixing gdm first, since gdm destroys the initially configured keyboard layouts from X and just pokes in its own selection (which is just a single layout).

Changed in gdm (Ubuntu Lucid):
assignee: nobody → Martin Pitt (pitti)
status: Invalid → In Progress
Martin Pitt (pitti) wrote :

*Phew*, it's finally working. I sent the patches to the upstream bug and will upload them soon.

They now implement the suggested behaviour, as long as the gconf key is empty, it uses the system-level layouts. The key stays empty as long as you just switch between the layouts configured on the system level (in GNOME or gdm), and is only written to if you pick a new layout in gdm or GNOME.

Changed in gdm (Ubuntu Lucid):
status: In Progress → Fix Committed
Changed in gnome-settings-daemon (Ubuntu Lucid):
status: In Progress → Fix Committed
Alkis Georgopoulos (alkisg) wrote :

Thank you, much appreciated.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-settings-daemon - 2.29.92-0ubuntu3

---------------
gnome-settings-daemon (2.29.92-0ubuntu3) lucid; urgency=low

  * Add 08_multi_keyboard_layouts.patch: Default to system settings for
    handling multiple keyboard layouts. (LP: #460328)
  * Add 09_indicator-display.patch: Always call show_hide_icon() in
    apply_xkb_settings(), not just when we set a different keyboard layout. We
    always want to show the indicator if we have multiple keyboard layouts
    available.
 -- Martin Pitt <email address hidden> Tue, 23 Mar 2010 17:09:20 +0100

Changed in gnome-settings-daemon (Ubuntu Lucid):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gdm - 2.29.92-0ubuntu4

---------------
gdm (2.29.92-0ubuntu4) lucid; urgency=low

  * 31-unify-power-strings.patch: Drop "Shut Down" → "Switch Off" hunk, still
    under debate.
  * Add 33-multi-keyboard-layouts.patch: Keep multiple system keyboard layouts
    for session. (LP: #460328)
 -- Martin Pitt <email address hidden> Tue, 23 Mar 2010 17:08:55 +0100

Changed in gdm (Ubuntu Lucid):
status: Fix Committed → Fix Released
Psy[H[] (vovik-wfa) wrote :

> Does it actually work with that syntax?
Surprisingly, yes.

Psy[H[] (vovik-wfa) wrote :

Confirming: with empty gconf keys g-s-d now correctly takes settings from console-setup.
When something is changed on user-level, only corresponding gconf key is being set. Others remain empty and work correctly.

I've tested addition of custom options by adding compose key option, and noticed that supposed "garbage" in "options" key may actually be some kind of headers. Gconf list entry of compose option goes like that: "Compose key compose:menu". So it seems to be correct behavior, because these options can be transferred correctly to console-setup by "apply systemwide". The only question is: why those redundant words are needed in gconf list anyway? But without them things break.
Maybe it is better to leave it as it is. The only downside: it is hard to manually type in gconf "options" list with all correct symbols in place. But I doubt many people will ever need to do it.

One last thing: wouldn't it be better to set /desktop/gnome/peripherals/keyboard/general/defaultGroup to 0 by default, instead of -1 ?

Psy[H[] (vovik-wfa) wrote :

Wow! I've found another glitch!
Check this: "layouts" key is empty, two layouts are set in console-setup. In my case "us,ru"
If you select russian layout in g-k-p and press "move up" button to put in on frst place, then gconf "layouts" key will be set to "[ru ,us ]". In this case those tab symbols are 100% garbage, as on next start of g-s-d "layouts" key becomes "[ru ,us ,us]". It is very close to the problem described in the beginning of this bug.

Psy[H[] (vovik-wfa) wrote :

In addition to second "us", the "defaultGroup" spontaneously changes it's value to -1 from 0

This bug is far from being closed...

Martin Pitt (pitti) wrote :

Adding control-center task for the gnome-keyboard-properties issue.

Changed in gnome-control-center (Ubuntu Lucid):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → Medium
status: New → In Progress
Martin Pitt (pitti) wrote :

control center patch sent upstream.

Changed in gnome-control-center (Ubuntu Lucid):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-control-center - 1:2.29.92-0ubuntu2

---------------
gnome-control-center (1:2.29.92-0ubuntu2) lucid; urgency=low

  * Add 04_keyboard_layout_gconf_names.patch: keyboard: Fix layout gconf key
    initialization for empty variants. (LP: #460328)
 -- Martin Pitt <email address hidden> Wed, 24 Mar 2010 09:24:11 +0100

Changed in gnome-control-center (Ubuntu Lucid):
status: Fix Committed → Fix Released
Psy[H[] (vovik-wfa) wrote :

Confirming. Problems described in comments #41 and #42 are fixed.

There is a small misguiding interface glitch left: if you have defaultGroup key set to 0, and you press "set defaults" in g-k-p, defaultGroup becomes -1, but corresponding checkbox in g-k-p interface is not being updated.

Martin Pitt (pitti) wrote :

Psy[H[] [2010-03-24 20:13 -0000]:
> Confirming. Problems described in comments #41 and #42 are fixed.

Finally :-) Thanks for testing.

> There is a small misguiding interface glitch left: if you have
> defaultGroup key set to 0, and you press "set defaults" in g-k-p,
> defaultGroup becomes -1, but corresponding checkbox in g-k-p interface
> is not being updated.

Hm, what is the "corresponding checkbox"? Can you please file a new
gnome-control-center bug about it?

Thanks,

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Psy[H[] (vovik-wfa) wrote :

Checkbox: "new window inherits layout of active window" or something like that. In new gnome it is a curious frontend to "defaultGroup" key.
Checkbox true = defaultGroup -1
Checkbox false = defaultGroup 0
And this checkbox does not update visually when "set defaults" button is pressed and sets defaultGroup to -1. Checkbox remains false.
I doubt this trifle worth a separate bug.

Changed in gdm:
status: Unknown → New
Changed in gnome-control-center:
status: Unknown → Confirmed
Changed in gnome-settings-daemon:
status: Unknown → Fix Released
Changed in gnome-control-center:
status: Confirmed → Fix Released
Changed in gdm:
importance: Unknown → Medium
Changed in gnome-control-center:
importance: Unknown → Medium
Changed in gnome-settings-daemon:
importance: Unknown → Medium
Changed in gdm:
status: New → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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