Man, the keymap bugs just keep coming. There are quite a few xkb keymaps which don't allow you to input ASCII characters at all. An example here is Russian, or Greek. It applies to most Cyrillic layouts, in fact. The standard way to use these keymaps is that you have both the 'native' keymap and U.S. English keymap enabled, and if you want to type ASCII characters, you switch to the U.S. English keymap. system-setup-keyboard had logic to cover most of these cases. The lines in systemd's kbd-model-map which look like this: ru ru,us pc105 - terminate:ctrl_alt_bksp,grp:shifts_toggle,grp_led:scroll are covering such cases. The key bits are 'ru,us' - which means 'enable both 'ru' and 'us' xkb layouts' - and 'grp:shifts_toggle' - which means 'write an X config which enables use of both shift keys to toggle the selected keymap'. So if you did an F17 install and picked Russian keyboard, you wound up with a /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf that looked like this: Section "InputClass" Identifier "system-setup-keyboard" MatchIsKeyboard "on" Option "XkbModel" "pc105" Option "XkbLayout" "ru,us" Option "XkbVariant" "" Option "XkbOptions" "terminate:ctrl_alt_bksp,grp:shifts_toggle,grp_led:scroll" EndSection Both ru and us layouts are available, and pressing both shift keys together toggles between them. I've tested this. It works. In newUI, we have totally lost this logic. If you pick Russian (Russia) at the language selection screen, and check 'Set keyboard to default layout for selected language.', your keyboard config will include a single layout - "Russian (Russian)" - with, obviously, no toggle key combination configured. This is basically death: you can't enter a workable ASCII username/password into firstboot without some way to toggle to the U.S. English keyboard layout. You're stuck. That is, once we fix https://bugzilla.redhat.com/show_bug.cgi?id=892097 . I know anaconda team is pretty firm against having this kind of magic in the installer any more, but this is a pretty icky case. To get a working install, a user of such a keymap has to do their keymap setup manually: they have to ensure they add both their native keymap and U.S. English and make sure they set up a keyboard combination for toggling layouts. If they miss any of that, death. I wonder, could we at least default to 'shifts_toggle' for any case where the user adds more than one keyboard layout? That's probably a closer match for our previous behaviour and would be marginally safer, as then the user would only have to make sure both layouts are selected, they wouldn't also have to jump through the hoop of setting up the toggle combo. In any case, we need this bug filed for CommonBugs purposes, if it doesn't get fixed.
Throwing this on the blocker list for discussion. The _easiest_ way forward here, I think, is to fix 892097 and strongly document this bug. An alternative would be to _not_ fix 892097 and document that instead: that would actually happen to be better for users of this kind of keyboard layout, as they're used to using U.S. English for firstboot, but it would be worse for users of the other kind of keyboard layout. Just by the numbers, I think it's better to fix firstboot and screw the users hit by *this* bug than leave firstboot alone and screw the users hit by *that* bug. In an ideal world we would fix firstboot and somehow fix anaconda to preserve the pre-newUI behaviour better, but that is probably a moderate amount of engineering (it would probably involve having anaconda read the kbd-model-map info somehow) and is something I think the anaconda team doesn't want to do.
Hm. That's interesting. Somehow or other, this actually worked better back at Beta - if you pick Russian as your language, you get both U.S. English and Russian keymaps configured in the Keyboard spoke (that's right) and a default layout switch key combo, Alt+Shift (it doesn't default to no switch combo). Is there any way we can get the Beta behaviour back here?
ah, so the Beta behaviour was just sort of differently-wrong: whatever language you picked at the first screen, so far as keyboards go, you got English (US) as your default keyboard and the native keyboard as your second keyboard, with Alt+Shift as a default combo for switching layouts. This happens to be rather a good setup for Russian etc. It's not _great_ for French etc as they'd probably expect the two to be the other way around. Still, if we can still twiddle the behaviour at this point, I think this ought to work rather nicely as a default: 'Native' layout as the first layout U.S. English as the second layout Shift+Shift as the default layout switcher AFAICS this would be acceptable to everyone, more or less. French etc users would be a bit surprised to have the U.S. layout available and may never use it, but as long as their native layout was the default, they shouldn't really mind. I expect Cyrillic-type users would cope whichever one was first in the list. And shift+shift was our 'default' layout switch combo in previous releases when we configured multiple layouts, so it makes sense to stick with that. We could either just default to that, or have that be what happens when the user checks the box. Thoughts? https://bugzilla.redhat.com/show_bug.cgi?id=866887 is very relevant here, btw, it is the bug which caused the change in behaviour between Beta and Final. This stuff is hard. :)
oh, there is one other option: just drop the checkbox and default to U.S. English for everyone. Make everyone who doesn't want U.S. English go through the keyboard spoke, stop trying to be fancy.
AFAICT, this "bug" (or the real situation becase the summary is simply not true) happens only when somebody chooses Russian as a language and checks "Set keyboard to default layout for selected language." (which is not checked by default) on the welcome/language screen. I'm sorry, but I believe that it is quite clear that it will result in Russian layout configured. And the main point, everybody can suffer the "5 clicks and 2 characters typed" nightmare of changing the keyboard configuration when installing OS. Keyboard configuration is not something like "I don't understand what it means so I'll rather let the installer's defaults here". Instead of taking this as a blocker I'd strongly recommend to close this as NOTABUG.
Er. The summary says 'default keyboard layout configuration'. The checkbox says 'Set keyboard to default layout for selected language'. Where are you getting "not true"? I disagree. Users don't expect the installer to do downright broken things. If they understand the two behaviours offered by the checkbox at all, what they're going to expect when it's checked is not 'a broken config no Russian person would ever pick' but 'the sensible default config anaconda always used to give them'. Remember the F17 experience here: at the language box you pick Russian, and then the keyboard dialog - where you *only pick one thing*, you don't pick from possible multiple combinations of xkb layouts - comes up with 'Russian' pre-selected. You accept that choice and continue, and when install completes, you have a sensible configuration, with both Russian and U.S. layouts. F18's code is incapable of reproducing this nice experience. That F17 experience is particularly important. Users of these layouts are conditioned by previous Fedora releases to expect that, when they see a 'keyboard layout configuration screen' with 'Russian' selected, everything is OK. For F18 this is very prominently not true. Sorry, but I wouldn't be happy with NOTABUG here. UPSTREAM, maybe, so you can claim this magical upstream i18n configuration unicorn we're waiting for should define what keymaps should be configured for what languages. But it's _definitely_ a bug. Just go do an F17 install in Russian, then an F18 install in Russian, then come back and tell me there's no bugs.
on the F17 vs. F18 thing: remember that F18's *apparent* behaviour if you check the box is very similar to F17's, but its *actual* behaviour is not. If you pick Russian and check the box, the hub comes up showing "Russian (Russian)" for keyboard. This is very similar to what F17 did, if you adjust for hub+spoke vs. wizard: F17 pre-selected "Russian" for you in the keyboard layout list after you picked Russia as your country, and all you had to do was accept it and move on, and everything was fine. Now we're telling everyone hub and spoke is awesome because it's more efficient, you don't have to change things you don't need to change. So you're Ivan Kurtzov, Russian Fedora user. You put your F18 DVD in the drive, boot up, start an install. You pick 'Russia' as your country. You see this 'Set keyboard to default layout for selected language.' checkbox and figure more or less what it does, you think you'd like to have anaconda set the keyboard layout for you just as it did before, so you check it. You wind up at the hub screen and you see "Russian (Russian)" under "Keyboard". Now. *Remembering you're Ivan*, you're not Vratislav who actually knows what's going on and that s-s-k is dead and the keyboard spoke now offers X layouts and everything else, do you even go into the Keyboard spoke to check? And if you do, do you actually realize that anything's wrong? After all, in F17, a 'keyboard layout' screen with only 'Russian' selected was *the right thing*. Maybe if you use the 'tester' box you realize something's wrong. Maybe. Sorry, but maybe this all makes perfect sense to the guy who wrote it and knows what's happening, and maybe to me because I have figured out what's happening, but from an ordinary user experience perspective it is at least a major regression in behaviour compared to previous releases and probably can reasonably be defined as 'broken'.
We have three votes for 'plan 2)' at https://bugzilla.redhat.com/show_bug.cgi?id=892097#c2 , plus vpodzime's take on this, which effectively adds up to -4 blocker for now, so setting this to RejectedBlocker. We can review all this on Monday and change tack if we need to, nothing is irreversible.
(In reply to comment #6) > Er. The summary says 'default keyboard layout configuration'. The checkbox > says 'Set keyboard to default layout for selected language'. Where are you > getting "not true"? "not true" lies in the fact that the checkbox is not checked by default (i.e. the default layout configuration). > > I disagree. Users don't expect the installer to do downright broken things. > If they understand the two behaviours offered by the checkbox at all, what > they're going to expect when it's checked is not 'a broken config no Russian > person would ever pick' but 'the sensible default config anaconda always > used to give them'. > > Remember the F17 experience here: at the language box you pick Russian, and > then the keyboard dialog - where you *only pick one thing*, you don't pick > from possible multiple combinations of xkb layouts - comes up with 'Russian' > pre-selected. You accept that choice and continue, and when install > completes, you have a sensible configuration, with both Russian and U.S. > layouts. F18's code is incapable of reproducing this nice experience. > > That F17 experience is particularly important. Users of these layouts are > conditioned by previous Fedora releases to expect that, when they see a > 'keyboard layout configuration screen' with 'Russian' selected, everything > is OK. For F18 this is very prominently not true. > > Sorry, but I wouldn't be happy with NOTABUG here. UPSTREAM, maybe, so you > can claim this magical upstream i18n configuration unicorn we're waiting for > should define what keymaps should be configured for what languages. But it's > _definitely_ a bug. Just go do an F17 install in Russian, then an F18 > install in Russian, then come back and tell me there's no bugs. The thing here is that the F17 installation provided a limited set of layouts defined in the s-c-k which was seen as a bug (and I agree with that) and it didn't provide a way to set multiple layouts for the installation process which is also a bug because especially when the installer gets the ability to create user accounts, people are going to want to enter their names with all characters they include and on the other hand passwords that may be impossible to write with the layout that supports all of the national characters needed for their full name.
(In reply to comment #7) > on the F17 vs. F18 thing: remember that F18's *apparent* behaviour if you > check the box is very similar to F17's, but its *actual* behaviour is not. > If you pick Russian and check the box, the hub comes up showing "Russian > (Russian)" for keyboard. This is very similar to what F17 did, if you adjust > for hub+spoke vs. wizard: F17 pre-selected "Russian" for you in the keyboard > layout list after you picked Russia as your country, and all you had to do > was accept it and move on, and everything was fine. > > Now we're telling everyone hub and spoke is awesome because it's more > efficient, you don't have to change things you don't need to change. So > you're Ivan Kurtzov, Russian Fedora user. You put your F18 DVD in the drive, > boot up, start an install. You pick 'Russia' as your country. You see this > 'Set keyboard to default layout for selected language.' checkbox and figure > more or less what it does, you think you'd like to have anaconda set the > keyboard layout for you just as it did before, so you check it. You wind up > at the hub screen and you see "Russian (Russian)" under "Keyboard". > > Now. *Remembering you're Ivan*, you're not Vratislav who actually knows > what's going on and that s-s-k is dead and the keyboard spoke now offers X > layouts and everything else, do you even go into the Keyboard spoke to > check? Well, here we are again with the "no need to check settings when installing OS" thing. I strongly believe that when somebody is installing an OS he or she is expected to check the configuration (twice) before hitting "Begin installation". The other story are things people don't understand or use and just want to let installer's defaults apply. > > And if you do, do you actually realize that anything's wrong? After all, in > F17, a 'keyboard layout' screen with only 'Russian' selected was *the right > thing*. Maybe if you use the 'tester' box you realize something's wrong. > Maybe. > > Sorry, but maybe this all makes perfect sense to the guy who wrote it and > knows what's happening, and maybe to me because I have figured out what's > happening, but from an ordinary user experience perspective it is at least a > major regression in behaviour compared to previous releases and probably can > reasonably be defined as 'broken'. These things have changed and I agree that they are not properly documented in the installation environment and people used to F17's installer may get confused. But this is not an issue in the code. Maybe in design or maybe in the documentation (do we have some step-by-step 10-page installation guide?). While I agree there are changes I believe these are not changes to anything worse (and thus wouldn't call them a regression).
"Well, here we are again with the "no need to check settings when installing OS" thing. I strongly believe that when somebody is installing an OS he or she is expected to check the configuration (twice) before hitting "Begin installation"" You personally may strongly believe that, but 'you don't have to go into every screen' is one of the stated benefits of the new hub/spoke model _according to the anaconda team_, of which you are a part. It's right there in https://fedoraproject.org/wiki/Features/NewInstallerUI : " Benefit to Fedora The hub and spoke model (see the User Experience section) means every user doesn't have to go through every page, making for a faster user experience and allowing us to add new pages without making a more complicated UI. "
There are not enough languages shown. Canadian French is different from Parisian (european French). The character set is the same, the keyboard is definitely not. CF uses a variation of qwerty, European French uses azerty.
Leslie: Um. the installer *does* list Canadian French.
(In reply to comment #11) > "Well, here we are again with the "no need to check settings when installing > OS" thing. I strongly believe that when somebody is installing an OS he or > she is expected to check the configuration (twice) before hitting "Begin > installation"" > > You personally may strongly believe that, but 'you don't have to go into > every screen' is one of the stated benefits of the new hub/spoke model > _according to the anaconda team_, of which you are a part. > > It's right there in https://fedoraproject.org/wiki/Features/NewInstallerUI : > > " Benefit to Fedora > > The hub and spoke model (see the User Experience section) means every > user doesn't have to go through every page, making for a faster user > experience and allowing us to add new pages without making a more > complicated UI. " That doesn't mean you should blindly skip everything you are not forced to see/confirm/configure. If you e.g. don't care about Network settings (cause you use cable-connected DHCP network), you are not forced to go to that screen. If you don't care about the repositories (installation source), you are not forced to go to that screen. But I believe everybody does care about their keyboard settings, especially when these settings are not 100 % standard (as e.g. for the russian language). We could probably go on with this "discussion" for a long time without getting to any usable conclusion. Let's try to focus on UI and logic changes (hopefully a new solution replacing libxklavier coming from the GNOME could help) for Fedora 19 that would make whole keyboard configuration part of the installation more clear and better understandable for users.
Adam If you choose the Canadian French, with the default keyboard shown in anaconda, or in gnome, could you please tell me which key to use to enter the french quotation marks? These appear as « quote » or english spacing is «quote». On level 3 of that key is the following ° character. Please advise. Back to Fedora core to Fedora 17. The keyboard for Canadian French has one extra key between the Z key and the left shift key. This is missing, and if we look at F18 alpha testing and now F19 alpha testing, it will be about 9 months elapsed. Is the keyboard layout going to give birth to that missing keytop? Not related to this bug, is the following. Like the USA keyboard with the Euro on the 5 key, the French(Canadian) keyboard should by default do likewise. I have sent a request to the government of Quebec/Canada to stipulate their decision on which key should hold the Euro symbol. Microsoft did not wait for decisions. Like the Latam keyboard layout, Microsoft put it at level 3 of the E keytop. Just need Fedora to decide about the Euro. We need it.
I don't know. This bug is not about the details of the French Canadian layout or physical keyboard. I don't know why you think the Canadian government is in the business of defining keyboard layouts, but so far as I'm aware it isn't, so I don't know that you're going to get much joy from your request. But please stop bringing up the same points about your particular layout again and again in bugs that aren't about it. If you have some specific issue with the Canadian French layout that you can describe clearly and concisely and that it is within Fedora's power to fix, please file a separate bug for it. If you don't, please at least stop clogging up other bug reports with it...
For F19 I would like to get back to the correct default for the chosen locale (ie not defaulting to US layout for everyone - though for better or worse GNOME 3.6 ignored that anyway I think). Failing that I probably agree it would be more consistent just to set US layout only for everyone (just like one might expect looking at the kbd setting in the F18 Hub anyway). I am assuming that this bug is still open since people feel the solution in F18 anaconda is not right, so let me update the summary to reflect that, and move this to F19. Leslie: for issues specific to the French Canadian layout please open one (or more) bugs against the Fedora xkeyboard-config package.
just defaulting to US in all cases and letting people add whatever layout they like from the spoke would certainly be the easiest option, and would remove a lot of the confusion. I think trying to pick a 'correct' layout even for every language/locale we provide could be a bit of a futile exercise, so that might be the way to go. Would anyone hate that?
(In reply to comment #18) > just defaulting to US in all cases and letting people add whatever layout > they like from the spoke would certainly be the easiest option, and would > remove a lot of the confusion. True, I would prefer that to what we did in F18 and current F19 anaconda. > I think trying to pick a 'correct' layout > even for every language/locale we provide could be a bit of a futile > exercise, so that might be the way to go. Would anyone hate that? Many locales have an associated well-known preferred kbd layout so it is actually not too hard to do it for them - the rest could just default to US layout for now I guess. Indeed anaconda have done this in the past and it /generally/ worked well. In fact we have some work in progress to factor out the region/language metadata from Anaconda to a separate package and I am still hoping that it can be integrated in the F19 timeframe so that the i18n team with the help of the community can worry about these things instead of the Installer team having to. (In reply to my comment #17) > (... - though for better or worse GNOME 3.6 ignored that anyway I think) That seems not true actually for current F18 Gnome installs anyway.
Adam I did work with a much earlier version of Fedora (before you were on board), and I did approach the standards committee for Canada and Quebec, to see if there was an official keyboard layout, and there was. An official layout was needed because of international trade, and to permit foreign vendors to produce keyboards to Canadian(Quebec) standards. Subsequently Quebec standardized my suggestion and I presented the ca(fr) to Linux. Chris Tyler (Toronto) did the coding change to create the ca(fr), which is what is used today. The Quebec Government procurements will stipulate the keyboard layout for PCs delivered to them, as will municipalities, and so forth. PC105 is a keyboard in common use. It has the extra key between the z key (lower left) and the shift key. This layout was correct with Gnome and Fedora 17, but disappeared for Fedora 18 and Fedora 19. FYI. The latam keyboard also has the extra key positioned in the same location.
Leslie: for Pete's sake, if you hijack one more bug to bang on about ca(fr)... this bug is rather obsolete at this point, anyhow, as we'll be using langtable data to set the keyboard config in F20, AIUI.
(In reply to Adam Williamson from comment #21) > this bug is rather obsolete at this point, anyhow, as we'll be using > langtable data to set the keyboard config in F20, AIUI. True, and I actually already have a patch for that. Now that we have the layout indicator, I think it shouldn't be a problem to switch the kbd layout from the default 'us' once language is selected. And we can also add the 'us' layout to language-default layouts that don't support ASCII (e.g. 'ru').
A couple of comments from reviews of F19 suggested that we could make it clearer exactly what the keyboard layout indicator _is_, and perhaps have it act as a switcher: http://all-things-linux.blogspot.ca/2013/07/installing-fedora-19.html (can't find the one who couldn't figure out what the indicator was right now) I'm not sure that switching layout as soon as language is selected would make sense for 'native+ASCII' layouts like Russian, because I _suspect_ people who use those layouts would probably be using ASCII during installation: the only things you have to type are passwords, passphrases and usernames, and I'm pretty sure people usually enter those in ASCII to avoid bugs with entering them in non-ASCII. I suspect the sensible default layout would be 'whatever a user of this layout combination would use to enter ASCII characters'.
(In reply to Adam Williamson from comment #23) > A couple of comments from reviews of F19 suggested that we could make it > clearer exactly what the keyboard layout indicator _is_, and perhaps have it > act as a switcher: I think it is pretty clear what the keyboard layout indicator is and it already acts as a switcher. When clicked, it switches to the next layout. And that's exactly what its tooltip says. So I think that should be okay. > > I'm not sure that switching layout as soon as language is selected would > make sense for 'native+ASCII' layouts like Russian, because I _suspect_ > people who use those layouts would probably be using ASCII during > installation: the only things you have to type are passwords, passphrases > and usernames, and I'm pretty sure people usually enter those in ASCII to > avoid bugs with entering them in non-ASCII. I suspect the sensible default > layout would be 'whatever a user of this layout combination would use to > enter ASCII characters'. That's a good point. So do you suggest to keep 'us' layout active for the non-ASCII language-default layouts? Example: Chosen lang: Default layout: Layouts: Active layout: Czech cz [cz] cz Russian ru [us, ru] us
(In reply to Vratislav Podzimek from comment #5) > AFAICT, this "bug" (or the real situation becase the summary is simply not > true) happens only when somebody chooses Russian as a language and checks > "Set keyboard to default layout for selected language." (which is not > checked by default) on the welcome/language screen. I'm sorry, but I believe > that it is quite clear that it will result in Russian layout configured. Just an opinion after stepping on the problem: "default" is not equal to "single". It seems related to the switching order and not to the presence of another layouts. However I agree there is the opposite point—why the another layouts should appear if user didn't select them explicitly. But changing / expanding the checkbox description is worth considering, as for me. I've just got following: 1. Start a fresh install of F19. RFRemix actually, but it doesn't differ here, as far as I understand. 2. Select Ukrainian language and check that "default" checkbox. 3. Create an ordinary user named with English symbols. 4. Reboot and fail to login since English layout is not available. This is quite confusing for another reason too: KDE shows English as the main layout for login manager—but it isn't available there. I know about different virtual consoles and xorg.conf, but that isn't the good case. Finally, my point #3 is confusing too. OK, you assume that user wants just the selected non-English layout—but why English is available for the user name then?
(In reply to Vratislav Podzimek from comment #24) > That's a good point. So do you suggest to keep 'us' layout active for the > non-ASCII language-default layouts? Yes, I think we should. :) That was always an implicit assumption for me. (In reply to Andrew Travneff from comment #25) I am updating the summary to make it clearer that is about keyboard layouts that provide ASCII input. For Ukraine I believe we should default to "us,uk". > However I agree there is the opposite point—why the another layouts should > appear if user didn't select them explicitly. But changing / expanding the > checkbox description is worth considering, as for me. Personally I still think we should just get rid of the checkbox and have sane defaults. With the metadata in langtable for keymap layouts that support ascii that should be possible now. I don't expect most users to be able to answer the checkbox "question" anyway, specially those that actually "need" it. It is confusing IMHO and a workaround for something that be automated with reasonable defaults. If the native keymap supports ASCII there is generally no need to add the US layout. (Though I heard for example that ASCII input is a bit awkward in the Czech kbd layout so there might still be some exceptions but that could still be handled by langtable.) Examples of native keymaps/layouts that provide ASCII: gb fr de dk es it jp kr and many more - I think all Western European keyboard layouts do and there is no need to assume they need US layout by default. If they should have a US layout keyboard then they should select it manually in the keyboard spoke.
(In reply to Jens Petersen from comment #26) > (In reply to Vratislav Podzimek from comment #24) > > That's a good point. So do you suggest to keep 'us' layout active for the > > non-ASCII language-default layouts? > > Yes, I think we should. :) That was always an implicit assumption for me. > > (In reply to Andrew Travneff from comment #25) > > I am updating the summary to make it clearer > that is about keyboard layouts that provide ASCII input. > > For Ukraine I believe we should default to "us,uk". > > > However I agree there is the opposite point—why the another layouts should > > appear if user didn't select them explicitly. But changing / expanding the > > checkbox description is worth considering, as for me. > > Personally I still think we should just get rid of the checkbox > and have sane defaults. With the metadata in langtable for keymap layouts > that support ascii that should be possible now. > I don't expect most users to be able to answer the checkbox "question" > anyway, specially those that actually "need" it. > It is confusing IMHO and a workaround for something that > be automated with reasonable defaults. That's exactly what I've been working on for some time in relation to some other patches for the Welcome spoke. I hope the patches should land quite soon in anaconda-patches and the master branch.
No additional info needed.
(In reply to Vratislav Podzimek from comment #27) > That's exactly what I've been working on for some time in relation to some > other patches for the Welcome spoke. I hope the patches should land quite > soon in anaconda-patches and the master branch. Excellent :-)
(In reply to Vratislav Podzimek from comment #27) > (In reply to Jens Petersen from comment #26) > > (In reply to Vratislav Podzimek from comment #24) > > > That's a good point. So do you suggest to keep 'us' layout active for the > > > non-ASCII language-default layouts? > > > > Yes, I think we should. :) That was always an implicit assumption for me. > > > > (In reply to Andrew Travneff from comment #25) > > > > I am updating the summary to make it clearer > > that is about keyboard layouts that provide ASCII input. > > > > For Ukraine I believe we should default to "us,uk". > > > > > However I agree there is the opposite point—why the another layouts should > > > appear if user didn't select them explicitly. But changing / expanding the > > > checkbox description is worth considering, as for me. > > > > Personally I still think we should just get rid of the checkbox > > and have sane defaults. With the metadata in langtable for keymap layouts > > that support ascii that should be possible now. > > I don't expect most users to be able to answer the checkbox "question" > > anyway, specially those that actually "need" it. > > It is confusing IMHO and a workaround for something that > > be automated with reasonable defaults. > That's exactly what I've been working on for some time in relation to some > other patches for the Welcome spoke. I hope the patches should land quite > soon in anaconda-patches and the master branch. Done, patches pushed. A video preview of the changed behaviour can be seen at: http://vpodzime.fedorapeople.org/locales_changes.webm
Looks good to me in anaconda-20.
I am testing F20. When I installed, I let the default (first line) which was highlighted (is the default a selection?) In the hub, I install the Canada French keyboard (French Canada). I eliminate / delete the English keyboard, as I do not have one. The virtual terminal (Ctl-alt-f2---Ctl-alt-F10 (yes to F10 if I select f2,f3,f4,,,) comes up in USA English I have to reset it with system-confg-keyboard and choose French Canada. The problem is that on the next boot, this is reset back to USA English. This did not happen with earlier Fedora versions. What I chose in the hub as priority was also what I wanted for the virtual terminals. Language of installation and keyboard use are not one and the same. The layouts are different, and the USA character positions for symbols such as pipe, ", # etc are not in line with Canada French, or many other keyboards. PLEASE FIX BEFORE GO LIVE. I reported this 5 months ago.
If you wont fix, should each virtual keyboard layout have the ability to retain it's requested keyboard layout? Do I have to run system-config-keyboard each time I reboot the system? The changes do not persist.
I can reproduce this using a Japanese install with the German keyboard layout added in anaconda and moved to top priority (the layout before adding the German one is the Japanese one, *not* US English). In the gnome session, the German keyboard is selected by default and works, in the virtual terminals the layout is US English. But I think this is different from what was originally reported in this bug here, it looks more like bug#1028207 .
Yes Mike. Bizzare. On one system F20 x64 version, the system-config-keyboard set in tty2-tty6, persists. On a reboot, the new layout is there. On my more recent F20 x64 installation, the system-config-keyboard to reset to the desired layout does not persist between reboots. I can say that I must try again, doing the command as root. I did system-config-keyboard as normal user. Perhaps I can make it persist. If it can be made to persist, by doing the keyboard layout change as root, then I believe this problem can stop being a blocker, (which it might be). I get around it as follows. In anaconda I set my root password to 1234567 Yes 1234567. On first boot, with the correct keyboard selected, I immediately reset the password which includes #!"@~}>{ characters.
Leslie: if you should still have a problem please report it in a new bug.