Can't switch keyboard layout in gksu

[Isriya Paireepairit]

The password which is required to enter in gksu dialog is usually in Latin text. While many international users have 2 keyboard layouts (Latin and their own layout, non-Latin in this case).

The scenario is when user choose non-Latin layout (e.g. Thai) and click some applications in menu that requires gksu (e.g. Synaptic). The dialog box appears but user can't input Latin password there. This could lead to be wrong password dialog.

Current solution is click on cancel to get back normal screen, switch keyboard layout and then try again.

[Amnon Aaronsohn (bla-cs)]

You can switch the keyboard layout using the the key sequence set in the "keyboard preferences" dialog, if such a sequence was set. However, there's no indication as to which layout is currently active.

[Isriya Paireepairit (isriya-pa)]

I think keyboard indicator applet is still important for this issue?

[Sebastian Heinlein (glatzor)]

you can disable the grab of your desktop by enabling /apps/gksu/disable-grab in gconf-editor. this has some security concerns, but could be a workaround for you.

[Konstantinos Togias (ktogias)]

I suffer from this issue too on Dapper. My native language is Greek. I use two layouts en_US and el_GR and switch bettween them with ctrl+alt+shift.
I have selected en_US layout as the default layout and clicked the "separate group for each window".
This way when I start an application it's window uses the default layout.

Unfortunatelly I realized that the window shown when an app needs my password to get root priviledges (eg. /usr/bin/sudo -H -S -p GNOME_SUDO_PASS -u root -- /usr/bin/update-manager) , do not follow this rule (they do not switch to the default layout when they appear at the screen).
I think this happens because when sudo window start, the focus is not taken from the previously focused window. This results in xlock and sudo using the layout selected for that window and not the default.

This issue is very very annoying for users that use more than one layout (and all non English speakers) and thus I think it should be take a highter priority.

I think the most appropriate sollution to this is to make sudo take the focus from the previously focused window and thus switch to the default layout.

An other approximation would be to show a message under or next to the password input box that would indicate the current layout.

A similar issue is faced on the password dialog that appears after locking the screen (xlock) (see bug #49222 - https://launchpad.net/distros/ubuntu/+source/gnome-screensaver/+bug/49222/ -).

[Leonty (leonty)]

I use 3 layouts (english, french, russian) and without indication it's really hard to guess which one was active when I got gksu dialog.
Gksu should show the current keyboard layout and caps lock state, like in windows xp login dialog.

[liorda (liorda)]

this affects the vast majority of (if not all) non-english speakers.

if we look at some other operating systems, most of them have an keyboard indicator on their login/password msgbox. i believe this is a good idea to implement.

[Philipp Kohlbecher (xt28)]

As reported in the (essentially duplicate) bug #134618, a caps lock indication would be helpful, as well.

[Rafik Elouerchefani (rafik)]

I'm running Intrepid beta. Sometimes I have to cancel gksu, switch keyboard layout, restart gksu.. That's annoying...
We need a keyboard layout indicator/switcher like on the "Unlock screen" dialog. (https://launchpad.net/ubuntu/+source/gnome-screensaver/+bug/49222)

Thanks.

[positivek (anonyhole)]

It's strange that the gnome-screensaver (bug 49222) and gksu / gksudo do not use the same dialog mechanisms. I think a bigger bug is that they should both use the same code.

I tried reporting it at Gnome. This bug ( http://bugzilla.gnome.org/show_bug.cgi?id=537486 ) was listed as "not a gtk bug". Whose is it, then? Who maintains gksu / gksudo?

Running Ubuntu 8.10 (Intrepid) with the latest updates. Gnome 2.24.1.

Note also that this could/should be coordinated with any and all other areas where login credentials are necessary, right? E.g. bug 14571.