Description of problem: Installation from a LiveCD using a non-US keymap is _hard_. The person needs to configure his keymap in DE, and then another set of keymaps in anaconda (for the installed system). To realize all the required steps is hard for me, and I work with anaconda every day. It's a no-go for many general users. I've played a bit today with Ubuntu installer, to see how they do it. They allow to change keymap in the installer, and it changes the keymap in the whole X session (equivalent to running setxkbmap). It is not tied to gnome control panel, which means gnome control dialogs or indicators (if you add them, by default they are not shown) display outdated information. The chosen layout is used for installation and in the installed system as the default one. I spent some time discussing this approach with Vratislav Podzimek and other guys. Here's a proposal how to simplify things in Anaconda in Live session: 1. Language changed from Anaconda should affect the current keymap. If I use the Anaconda keymap indicator, or change the top-most entry in the keymap list, or use keyboard shortcut to change keymaps, it should really change the keymap (like setxkbmap). 2. Use the same keymap spoke for DVD and Live. That means the "test your keyboard" box can be un-grayed again in the keymap spoke. The ugly ugly instructions how to change keymap can be erased. (The instructions should still note that this spoke shows which keymaps will be available in the installed system and that the user should make sure that he provides the password using the same keymap as used by the installed system). 3. In the rare case where the user changed his keymap prior to running Anaconda, and then selected a different language/keymap in the initial screen, show a warning triangle over the keymap spoke. That will force the user to enter the spoke and confirm his choices, or adjust the settings. This proposal means removing a lot of if-blocks, thus cleaning the code, and it also provides a better experience for the user - the installation language can be configured inside the installed -> beautiful. There are some corner cases if the user pre-configures different keymaps in the system before running Anaconda (most of them are just cosmetic), but overall this provides a much better and simpler experience for the majority of users. Version-Release number of selected component (if applicable): anaconda 20.8
(In reply to Kamil Páral from comment #0) ... > 3. In the rare case where the user changed his keymap prior to running > Anaconda, and then selected a different language/keymap in the initial > screen, show a warning triangle over the keymap spoke. That will force the > user to enter the spoke and confirm his choices, or adjust the settings. ... +1 on your proposal. Thanks for your suggestions. The installer can use systemd to query and set the locale settings (including the keymap). Settings in the desktop session can be obtained from systemd-localed[1] (equivalent to running the "localectl" command). The only issue I see is that, in the Live environment, if the installer has already started, the user could change the locale settings in the desktop session. systemd supports client notifications[2], so, in principle, the installer could update itself, but at some point the installer has to know what the actual intended configuration is. That would presumably be when the user clicks Begin Installation. Displaying a locale-configuration-changed icon is a good idea. That is similar to what is already done for the Software Selection when the user changes the Installation Source on the DVD. [1] The localed API is documented here: http://www.freedesktop.org/wiki/Software/systemd/localed/ [2] "Whenever the system locale or keymap is changed via the daemon PropertyChanged signals are sent out to which clients can subscribe."
Well there is another issue. On the Live image, if the user changes the language from Gnome Control Center (Settings:Region & Language), the user is prompted to restart the desktop session. If the installer is already running, restarting the desktop session would terminate the installer, because restarting the desktop session terminates any processes running in the desktop session.
(In reply to Steve Tyler from comment #2) > Well there is another issue. On the Live image, if the user changes the > language from Gnome Control Center (Settings:Region & Language), We're talking about keymaps here, not languages. When you change the keymap in gnome control center, you are not requested to relogin. But you're right that user is free to close anaconda or quit the session during installation. He should at least confirm that action, so that he doesn't do that with a simple misclick. That's bug 864470.
Prompting the user before terminating the installer is definitely a good idea, since the Region & Language dialog is not part of the installer, it is not apparent that changes made in the R&L dialog would have any influence on what the installer does or does not do. The issue is that the user is likely to configure _both_ the language and the keymap at the same time. The need to restart the desktop session after changing the language appears to be a design defect -- the desktop should be able to reconfigure itself after a language change. The installer should be able to do the same, of course ...
The core idea of this proposal is that the user doesn't need to visit gnome control center at all, not even know about it.
OK, so what happens if the installer is running, and the user changes the keyboard settings from Gnome Control Center?
Created attachment 792140 [details] screenshot showing Region & Language restart button after keyboard and language are changed while installer is running
This is better than I thought. The user does not need to restart after changing the language. I clicked the close icon next to the restart button, and then closed R&L. systemd has the expected settings: $ localectl System Locale: LANG=es_ES.utf8 LC_NUMERIC=en_US.UTF-8 LC_TIME=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_PAPER=en_US.UTF-8 LC_MEASUREMENT=en_US.UTF-8 VC Keymap: es X11 Layout: es
Steve, please stop confusing this report(!). This is not about language, this is about keymap. Language is configured in anaconda in the initial screen and there are no influences between anaconda language and system language. > OK, so what happens if the installer is running, and the user changes the > keyboard settings from Gnome Control Center? The same as always, the keymap gets switched. That always worked and there's no change in behavior. This proposal says that you should also be able to switch the keymap from Anaconda. It won't be reflected in the gnome indicator (which is hidden by default), unless we add DE-specific code, but at least it will _work_.
In the attached screenshot, the installer shows "es" in the upper right corner, and "English (English (US))" under KEYBOARD. I am confused, which one is correct?
I've already responded to this in comment 9 and in comment 0. Things will never be in perfect sync unless anaconda adds a ton of DE-specific code for every DE out there. This proposal intends to improve the situation with just a few simple adjustments (80-20 principle). You complain about things that I specifically listed as _not being covered_. So if you want those missing 20% fixed so badly, and you want anaconda devs to spend a lot of time on it, can you please file a separate report asking for full GNOME integration and stop obfuscating this _intentionally_ very simple proposal? Thank you.
Created attachment 792225 [details] screenshot showing KEYBOARD LAYOUT dialog with "es" in layout selector, but "English (English(US))" in the layout list I configured "es" from Gnome Control Center, but Spanish is not in the layout list. I am confused ... BTW, I sometimes forget what those little letters mean: Is "es" Spanish, or is it Estonian? I am confused ... Tested with: $ qemu-kvm -m 4096 -hda f20-test-3.img -cdrom ~/xfr/fedora/F20/Alpha/Fedora-Live-Desktop-x86_64-20-Alpha-TC2-1.iso -vga std -boot menu=on
(In reply to Kamil Páral from comment #11) > ... Things will > never be in perfect sync unless anaconda adds a ton of DE-specific code for > every DE out there. ... systemd-localed is the common element that enables integration. The DE is irrelevant, if it is using systemd-localed. Of course, I could be confused ... And I now see that the installer is already using systemd-localed. That's excellent: $ less -N anaconda-20.9-1/pyanaconda/keyboard.py ... 642 class LocaledWrapper(object): 643 """ 644 Class wrapping systemd-localed daemon functionality. By using safe_dbus 645 module it tries to prevent failures related to threads and main loops. 646 647 """ ...
Patch that implements what was suggested in the comment #0 sent to anaconda-patches [1] [1] https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-September/005699.html
(In reply to Steve Tyler from comment #13) > (In reply to Kamil Páral from comment #11) > > ... Things will > > never be in perfect sync unless anaconda adds a ton of DE-specific code for > > every DE out there. ... > > systemd-localed is the common element that enables integration. The DE is > irrelevant, if it is using systemd-localed. Of course, I could be confused > ... That would rely on all DE's using systemd-localed for storing current user's configuration as the system-wide configuration which is nonsense.
Isn't systemd a standard component of Fedora? DE's that do not use systemd need to be upgraded to use systemd. That makes sense to me, anyway ...
anaconda-20.12-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.12-1.fc20
Package anaconda-20.12-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-20.12-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-16040/anaconda-20.12-1.fc20 then log in and leave karma (feedback).
With F20 Alpha TC5 Live, keymap selection works great in Anaconda. Thanks. The current keymap can be changed, the input box can be used to test the keys. This doesn't work, however: "3. In the rare case where the user changed his keymap prior to running Anaconda, and then selected a different language/keymap in the initial screen, show a warning triangle over the keymap spoke. That will force the user to enter the spoke and confirm his choices, or adjust the settings." I used gnome settings to add Czech and English layouts and kept Czech active while starting Anaconda. On the initial language screen, Czech was active and displayed in the anaconda indicator. I picked English as the installation language, and after proceeding to the main hub, the anaconda indicator was switch to "us" and only English is present in they keymap spoke. The spoke doesn't have a warning icon and I can't switch the keymaps using anaconda indicator (only "us" is present). Actually, I think this behavior is fine as well. It's very visible that English is active and anaconda allows to add keymaps and switch between them. The only drawback is that gnome keymap indicator might not be in sync with anaconda indicator, but there's not much we can do about it. And after thinking about it, there are some hard design choices when implementing the suggestion above anyway. I'd say thanks, keep it this way. We will see what users are going to say about this (some of them might be initially confused, because they might be used to pre-configure the keymap before running anaconda, due to previous restrictions).
anaconda-20.13-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.13-1.fc20
anaconda-20.14-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.14-1.fc20
anaconda-20.15-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.15-1.fc20
anaconda-20.16-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.16-1.fc20
anaconda-20.17-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.17-1.fc20
anaconda-20.17-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.