Red Hat Bugzilla – Bug 854557
Keyboard layout testing doesn't work the way the comment above it describes
Last modified: 2013-05-12 19:31:55 EDT
Description of problem:
Above the text input field to test the keyboard layout it says 'Test the selected layout below:', which means (as I understand it) that the layout for typing in the input field depends on the selected language in the list. But this is not the case, the layout stays at US, even if you have another language selected.
However, below the input field it says 'Alt + Shift to switch layouts', and that does work; it switches the layout, but there is no indication of which layout is currently being used.
Version-Release number of selected component (if applicable):
There should be an indicator near the test input field that shows the active layout, and the 'Test the selected layout below:' should be replaced by a hint that mentions Alt + Shift.
When using Alt + Shift the active layout should be indicated by selecting it in the list, and selecting a layout in the list should change the active layout for the input box accordingly.
(In reply to comment #0)
> Description of problem:
> Above the text input field to test the keyboard layout it says 'Test the
> selected layout below:', which means (as I understand it) that the layout
> for typing in the input field depends on the selected language in the list.
> But this is not the case, the layout stays at US, even if you have another
> language selected.
We are not switching layouts on selection change. Text above the input field is wrong and I've just sent patch fixing this to anaconda-patches list.
However, layout indicator probably cannot be easily implemented (GNOME, KDE and others handle layouts in a different way) and even if we implement it, I believe it should be placed somewhere else, not only in this particular screen.
Vratislav, how would you like to handle this? I assume the patch you mentioned has been in stable for a long time. Should the report be closed or do you see more to do here?
(In reply to comment #2)
> Vratislav, how would you like to handle this? I assume the patch you
> mentioned has been in stable for a long time. Should the report be closed or
> do you see more to do here?
That patch has not been pushed to stable, unfortunately. It got lost in the anaconda-patches list. I'll resend it now, but it is a string change that will break translations.
This still never got pushed, and is still kinda wonky in current stable, unfortunately. Proposing as NTH in case we want to try and get this in, though if it breaks string freeze that's a problem I guess.
(In reply to comment #4)
> This still never got pushed, and is still kinda wonky in current stable,
> unfortunately. Proposing as NTH in case we want to try and get this in,
> though if it breaks string freeze that's a problem I guess.
The patch has been pushed to master a while ago , but since it breaks string freeze it wasn't approved for f18-branch.
Discussed at 2012-01-03 go/no-go meeting: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-01-03/f18_final_gono-go_meeting.2013-01-03-17.01.log.txt . Rejected as NTH: the fix just adjusts the label on the dialog, which doesn't really address the larger problem that the UI here kind of sucks, and would necessitate new translations.
commonbugs this one.
Note the 'fix' for this adjusts the label on the layout test box, but does not add an indicator for the currently-active layout either to the Keyboard spoke or to any other screen in the installer where text input is required.
(In reply to comment #8)
> Note the 'fix' for this adjusts the label on the layout test box, but does
> not add an indicator for the currently-active layout either to the Keyboard
> spoke or to any other screen in the installer where text input is required.
Exactly, but the indicator is also planned for the future versions.
well, my point was more or less that we may not want to close this bug _only_ with the label fix, given that the summary includes "lacks indication of the active layout". So we might want to leave this open until that is added, or alternatively open a new bug and change the summary on this bug.
(In reply to comment #10)
> well, my point was more or less that we may not want to close this bug
> _only_ with the label fix, given that the summary includes "lacks indication
> of the active layout". So we might want to leave this open until that is
> added, or alternatively open a new bug and change the summary on this bug.
I believe that the lack of layout indication is a separate issue and affects various places of the installer (especially the ones with password entries). Thus we should probably create a new bug for it and change this one's summary. I can do that if nobody is against it.
Works for me.
Done, see bug #895913.
I use French Canadian Keyboard (ca) and I am doing an English USA installation,
To test the keystrokes that will be active for the virtual console I delete the USA English keyboard definition, which places the French Canadian as the only keyboard. I test and yes, I get the correct characters being shown against the keys except..
A new change is required to add the Euro key as the alt-3 E
In Fedora 17, we had the choice to add the Euro to alt-3 5 or alt-3 E.
Keyboards are beginning to be stenciled with the Euro on the E key at level 3.
My level 3 of the 5 key is ¤ whereas my level 3 E key is e (needs to be Euro)
I reinstall the English USA, and select menu as my keyboard toggle.
The graphical image is not correct. In Fedora 17 and earlier, the image showed a pc105 keyboard.
to the left of the z key (french keyboard is « » and ° ) The english keyboard at that same position has < > and Dead key).
To the right of the M key giving <, and key giving >. Essentially the <> are repeated.
Please show the visual layout of the image to match the visual image shown with Fedora 17 and earlier Fedora versions.
By the way, KDE has the Euro symbol with the level3 E. KDE appears to do a better job of keyboard handling
*** Bug 907504 has been marked as a duplicate of this bug. ***
This problem still persists fully in Fedora 19 TC1. Is it going to get fixed?
Please refer to KEYBOARD LAYOUT FOR CF as was presented in Fedora 17.
In the layouts there is a missing key between the Z key and the left shift key
Here it is in large. For ca(fr) you must have PC105.
| » |
| « ° |
When this keyboard is used for USA the « is replaced by <
and the » is replaced by >
and the ° is a dead key.
Characters are Open Guilmet and Closed Guilmet
There is also a norm that matches the USA keyboard with the EURO on the 5 key
This is also the norm for the Canadian French. ca(FR).
I have written to the Quebec Government to have them confirm
a) the extra key between the Z and the Upper case on the bottom left of the keyboard
b) Where do they want a permenant euro symbol. It may be either on the 5 key level 3 or the E key level 3
Hope they respond soon
Leslie: for the tenth time, your problems with the CF layout are not a part of this or any other bug. Please file separately.
Who is responsible for the keyboard layout. I tried with Gnome support, I tried with KDE support. Is it X? Since this first occurred in Anaconda, I attached it to anaconda. Bugzilla comments are, if not sure, take a guess as to application.
Now back to anaconda and F19. The keyboard test area for the very first keyboard, the default, now reflects the keyboard definition.
My testing with F19 was positive for the problem. So, as far as I am concerned, adding a second keyboard layout and then moving it to the first position works. The test area reflects the keyboard layout.
So this bug may be closed.
it's really not that simple. there are various tricky interactions when it comes to keyboard layouts, and your reports tend to be long and rambling and cover multiple issues. in general, we're basically aware of what stuff needs to be improved, and there are existing bugs to cover most of it.
I have switched to USA English with Euro on 5 Key, So when I need to enter the Euro. It is easy.
Click on keyboard menu, select English, enter Euro and then switch back to Ca(FR).
Alternative is use Gnome Tweak, or KDE tweak.
I have my work-around. I will not be following up.
Everything properly addressed in this bug is fixed now: as of 19 Beta TC4 the box behaves as the text says, and there is a layout indicator present. It's a lot clearer. Let's close this out.