GNOME Bugzilla – Bug 585290
Try harder to use the keyboard layout passed by gdm
Last modified: 2011-02-03 14:14:49 UTC
In GDM, the user can select a keyboard layout. If it's the first login, this layout will get used by g-s-d (and put in gconf). However, if it's not the first login, this layout will only get used if it was already in gconf. With this patch, g-s-d tries harder to satisfy what the user wanted by adding the layout in gconf if needed (even on non-first logins).
Created attachment 136235 [details] [review] Try harder to use the keyboard layout passed by gdm We try harder in the case where the user already has some keyboard configuration set in gconf.
Created attachment 136238 [details] [review] Try harder to use the keyboard layout passed by gdm We try harder in the case where the user already has some keyboard configuration set in gconf.
Users become upset if their carefully configured keyboard layouts become messed up just because they forgot to make a selection in the gdm combo. Really, I've been there, i've gotten the upset bug reports from both sides - those that insist on picking their layout on the login screen and have it survive in the session, and those that want the freedom to ignore the combo box on the login screen and still get their preconfigured layouts in the session. There is no way to win here.
(In reply to comment #3) > Users become upset if their carefully configured keyboard layouts become messed > up just because they forgot to make a selection in the gdm combo. Err, this shouldn't happen: since their preferred layout is saved in ~/.dmrc, gdm will just have the right thing in the combo by default. If this happens, then there's a bug in gdm.
their preferred layout is only saved in .dmrc if they ever selected it in gdm, which they don't
Ah, I missed this. Hrm. I think gnome-keyboard-properties (and gnome-settings-daemon, when it sets the initial keyboard layout in gconf) should also update ~/.dmrc. After all, if I want to use a german layout for my account, I'd also want this for my password, I guess.
your guess, but you will hopefully also handle the bug reports from people who suddenly can't enter their password anymore after making a change in the session, when they never payed attention to the combo box on the login screen before... As I said above, you can't win this.
I would agree with Matthias. IMO there is something like 50-50 split - some people want their session layout to be used in gdm, some people got really frustrated when they suddenly cannot enter the password. > After all, if I want to use a german layout for my account, I'd also want this for my password, I guess. Actually, this is not necessarily true, especially if there is >1 user of the system. I guess it would be more correct to manage gdm layout and session layout separately. It is ok to use the gdm layout for the first session - but after user configured something in g-k-p, we should not synchronize them any more, in any direction.
We should probably just remove the keyboard list from the panel entirely. Instead, if it's the first time a user has logged in, we should show the language and keyboard drop downs in the center of the screen, like: "Please select your language and keyboard layout and login: "
IMHO there is some overestimation of the link between locale and keyboard layout. While it perfectly makes sense to give user choice of the locale in GDM, it would be impolite to assume that user always automatically wants his layout to be adjusted. If user did not configure anything explicitly (uses system defaults) - may be(?), he'd be also happy with the layouts 'derived' from locale (chosen in GDM). But if he already has something chosen in g-k-p, I would consider quite inappropriate to ignore his will.
The current behaviour seems pretty inconsistent to me, though. After logging in the first time, you can't change the keyboard layout for that user in gdm any more, ever, since g-s-d stores the current $GDM_KEYBOARD_LAYOUT one in gconf if it's empty (in [1]. If it keeps doing that, and Vincent's patch gets applied, then gdm keyboard selection always works. If Vincent's patch is not applied, then gdm shouldn't export $GDM_KEYBOARD_LAYOUT unless the user actually selected one, or [1] needs to be modified to not store it in gconf if it's already the default layout. Then the behaviour is consistent as well: It will default to the system keyboard layout until you explicitly select one in gdm (which can happen at the first or 23rd login).
[1] http://git.gnome.org/cgit/gnome-settings-daemon/tree/plugins/keyboard/gsd-keyboard-xkb.c?id=632055166859aba574b8103a3f3d609c1e130b13#n239
Matt, your patch makes sense, except for a couple of details: 1. the constant 3. Could you please use (xkl_engine_get_max_num_groups(xkl_engine) - 1) instead? 2. Please do not make list larger than ... (yes, 4). So if you need to remove the last layout - do so!
(sorry, my last comment was for Vincent)
Created attachment 144848 [details] [review] Try harder to use the keyboard layout passed by gdm Note that I can't test the patch right now. Hopefully, I didn't do anything stupid. (I can at least say it compiles fine)
That part: + if (found_node) { + if (g_slist_position (layouts, found_node) > max_groups - 1) { ... I would remove altogether. That scenario would mean serious bug in some other code. Other than this, it looks fine to me. Anyone having any objections against that code?
The code is committed (without first check for the found node). Thank you, Vincent!
Created attachment 149101 [details] [review] Part of the patch I forgot to attach
I don't think magically adding an unknown keyboard combination to the layout is going to help the user at all. What we need is to turn the keyboard switcher applet into a status icon and show that when there is more than one layout. I know that svu doesn't want to let go of his applet, but it still needs to happen...
(In reply to comment #19) > I don't think magically adding an unknown keyboard combination to the layout is > going to help the user at all. What we need is to turn the keyboard switcher > applet into a status icon and show that when there is more than one layout. Well, you'd still need the combo too. (unless you completely remove support for this)
Mathhias, I would really like to let my applet go (seriously), but I do not see a better solution for a moment. The requirements to better solution (as I see it): - Should be able to use indicator gtk widget (from libgnomekbd). This is quite firm requirement - because there is a number of plugins that people do use, and, most importantly (even though it is in unofficial) - ability to switch between textual labels and flags - Preferably (something in between between "mandatory and optional":) - not use notification area (already cluttered as it is). - As you say, hide and show dynamically, when Nlayouts > 1. If there is a way to meet these requirements and drop the applet, pray tell!
No, there is no way to use a widget in a statusicon. That doesn't meant that you cannot do your flag-raising thing, just that it needs to be done differently. And using a statusicon is pretty much unavoidable, since there will not be any applets in gnome-shell. Also, the keyboard layout switcher very much belongs right next to the other status indicators: volume, network, battery. Your clutter concern will be addressed in gnome-shell by reserving the top panel notification area for a fixed set of 'system' status indicators, and relegating all the 'random app' statusicons to the message tray at the bottom.
Matthias, I realize that at some point I'll have to rewrite gtk widget to clutter widget for gnome-shell. But that's not exactly same thing as notification area app, is it?