Bug 1039185 - When configuring both 'native' and US layout for a layout that cannot input ASCII, US should be first in the list
Summary: When configuring both 'native' and US layout for a layout that cannot input A...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: CommonBugs
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-06 20:53 UTC by Alexey Torkhov
Modified: 2021-01-04 23:27 UTC (History)
19 users (show)

Fixed In Version: anaconda-34.3-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-01-04 23:27:52 UTC
Type: Bug


Attachments (Terms of Use)

Description Alexey Torkhov 2013-12-06 20:53:41 UTC
Description of problem:
In locales which default keymap does not contain non-ASCII characters, it should be prepended by US keymap. So, for example default keymap settings for russian locale should be "us,ru" and not "ru,us" like it is now. This is needed because almost everything that should be typed during installation is ASCII-only. That is like "1G" for partition sizes, user logins, user passwords, hostnames, etc... And the most annoying thing is need to switch layout before entering password in DM. I believe almost everybody who knows does this change during installation or after.

Comment 1 Adam Williamson 2013-12-06 21:10:18 UTC
I tested every switchable 'legacy' layout I could find in kbd. Every single one has US as the 'default' and native as the 'variant' layout - when you first load them, you're typing in US, and you have to hit the switcher combo to type the 'native' characters.

So that strongly indicates Alexey is correct, and our default for X should be the same: US layout first, 'native' second.

Comment 2 Adam Williamson 2013-12-06 21:11:13 UTC
If the fix for this is sufficiently simple I'd like it if we could do it for F20 final; it'd be nice to get as much keymap stuff right as we can for F20, we're already doing a lot better than 18 and 19. And obviously, anaconda behaviour can't be fixed post-release.

Comment 3 Vratislav Podzimek 2013-12-09 13:57:28 UTC
One-line patch posted to anaconda-patches, but I'm not very eager to push it because I know bugzilla is full of complaints that in F18/F19 people expected to type with e.g. russian layout when they chose russian language without the need of switching layouts.

Comment 4 Adam Williamson 2013-12-09 16:02:55 UTC
hmm, really? do you have references? obviously we want to respect what the majority of users would expect...

Comment 5 Alexey Torkhov 2013-12-09 16:33:05 UTC
If one does want to type in russian layout after login without switching then he need to set ru,us in his DE and have us,ru system-wide - because otherwise he should switch to type his username and/or password.

Comment 6 Arkady L. Shane 2013-12-09 17:24:05 UTC
This bug was fixed many years ago in rhpl (yeah, http://koji.fedoraproject.org/koji/buildinfo?buildID=103687), but patches was not pushed to git. So problem is still relevant.

If it will be fixed, I think it will be a greate gift for Christmas:).

Comment 7 Adam Williamson 2013-12-09 18:53:27 UTC
vpodzime: I had a look through bugzilla and could not find any bug where a native user asserted that they expect the default ordering to be native,us , but I'll keep looking through old bugs. Also marking this bug 'i18n': people who use layouts of this kind, it would be very helpful if you could provide input here, say whether you'd usually expect the first layout in the list to be your native layout or US.

Comment 8 Mike Ruckman 2013-12-09 18:54:24 UTC
Discussed in 2013-12-09 Blocker Review meeting [1]. Voted an AcceptedFreezeException. A fix will be considered past freeze, but we should double-check with more native users of affected languages that this is what they expect.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-12-09/

Comment 9 Arkady L. Shane 2013-12-09 19:15:38 UTC
Everything began from this bug: https://bugzilla.redhat.com/show_bug.cgi?id=473056 and this patch: https://git.fedorahosted.org/cgit/rhpl.git/commit/?id=e0dbbeccc3c7d2bbc07c51e683bb1918a78ea72e

Also for Russian this issue was reverted https://git.fedorahosted.org/cgit/rhpl.git/commit/?id=64a108764c746362d9afdd24b380c61c9bad3fac

But then last commit has not appeared in system-config-keyboard.

Comment 10 Igor Gnatenko 2013-12-09 19:32:44 UTC
+1 FE

Comment 11 Alexei Panov 2013-12-09 19:33:43 UTC
I agree. US should be first in the list.

Comment 12 Mikhail 2013-12-09 19:59:41 UTC
+1 I agree. US should be first in the list.

Comment 13 Vernat 2013-12-09 20:01:26 UTC
+1 I agree!!!

Comment 14 Vladimir 2013-12-09 20:06:27 UTC
Agree with this too

Comment 15 Arsen B. 2013-12-09 20:08:55 UTC
I agree with Arkady L. Shane — it really will be a greate gift for Christmas and NY.
+1.

Comment 16 Ivan Romanov 2013-12-09 20:36:35 UTC
+1 US must be first.

Comment 17 Peter Lemenkov 2013-12-09 20:37:58 UTC
Could we please hardcode LANG=C keyboard layout as the first one on systems with several locale layouts forever? If remember correctly the issue was "fixed" few times, then revived again (patches were not applied, or dropped later). This is really annoying and should be fixed ultimately.

Btw I don't know anyone who configured "ru,us" as a locale order. Not a representative sample but anyway - you asked for it.

Comment 18 Adam Williamson 2013-12-09 21:06:50 UTC
arkady: none of that is relevant, rhpl is not used in Fedora any more. We already know the change that is needed to change this, it's just a question of doing it. This relates to xkb layouts, btw, not kbd ones.

Comment 19 Adam Williamson 2013-12-09 21:09:16 UTC
peter: we completely changed how keyboard layouts happen in Fedora between F17 and F20...several times. that's why things appear somewhat chaotic. system-setup-keyboard doesn't exist any more, anaconda gives all xkb layouts as options and relies on localed to pick matching kbd layouts, langtable is a thing now, and in f20, we have a set of kbd layouts generated from xkb layouts. It's a lot to keep track of. But I and vpodzime know how it all works, all we need on this bug is input from users to confirm that the order ought to be us,native not native,us; we can only rely on user feedback to know which is right.

Comment 20 Arkady L. Shane 2013-12-09 21:24:33 UTC
(In reply to Adam Williamson from comment #18)
> arkady: none of that is relevant, rhpl is not used in Fedora any more. We
> already know the change that is needed to change this, it's just a question
> of doing it. This relates to xkb layouts, btw, not kbd ones.

Sure I know it. I only said when this trouble has appeared as your could get more information.

Comment 21 pavel.nedr 2013-12-09 21:37:56 UTC
Hi, I am russian-speaking, and I espose this bug. My default layout in whole system is 'us'. This is the only comfortable setting to work, especially in the setup.

Comment 22 Mikhail Kulemin 2013-12-09 23:39:02 UTC
+1. I am russian-speaking and I also can confirm that US layout should be the first in the list - it is the most convenient way. I also don`t know anybody who use "ru, us" order of layouts.

Comment 23 Adam Williamson 2013-12-10 04:22:12 UTC
Received another confirmation from G+, from Jonathan Dieter:

"FWIW, here in Lebanon, most of our users prefer the English interface and keyboard layout, and only switch to the Arabic layout if they're wanting to type in Arabic. Don't know if that helps at all."

Comment 24 Adam Williamson 2013-12-10 05:48:56 UTC
Hum, just thought of a possible consequence if we change this: would you always wind up with just plain US (rather than a legacy switchable layout) as the console layout from localed, if we put US ahead of the 'native' layout in the X config anaconda writes?

Comment 25 Vratislav Podzimek 2013-12-10 08:12:59 UTC
(In reply to Adam Williamson from comment #24)
> Hum, just thought of a possible consequence if we change this: would you
> always wind up with just plain US (rather than a legacy switchable layout)
> as the console layout from localed, if we put US ahead of the 'native'
> layout in the X config anaconda writes?
Yes, you'd do. And while that could probably be fixed, because xlayouts and vckeymap are now separate kickstart options [1] and thus can simply be set separately from the installer's GUI, I'm not sure that would work for all languages. Do all legacy switchable console keymaps work as the us keymap by default? Cause if we make the 'us' layout default in the GUI and people will use it for entering LUKS password, they'd need the same layout/keymap as the console keymap on boot.

Comment 26 Vratislav Podzimek 2013-12-10 08:13:35 UTC
[1] https://fedoraproject.org/wiki/Anaconda/Kickstart#keyboard

Comment 27 Adam Williamson 2013-12-10 16:04:02 UTC
"Do all legacy switchable console keymaps work as the us keymap by default?"

See comment #1.

Still, given c#24 and c#25 this sounds more like F21 stuff, unfortunately :( I really wanted to try and get everything as right as possible in F20. Never mind.

Comment 28 Adam Williamson 2013-12-13 00:45:12 UTC
The more I think about this one, the ickier it gets.

We could probably make it work for cases where the user just accepts whatever layout we decide: we can configure X so the order is 'us,native' and then go 'behind the scenes' and set the console layout to 'native'. Okay. Fine.

But what about cases where the user actually picks some keyboard layout configuration?

Say you're Russian, but you want to install in English (I think this is quite common for techies). You might go into the Keyboard spoke and add the Russian and US English layouts, with US English first. Would we give you 'ru' layout on the console? Probably not. But we would if you installed in Russian and just accepted your layout, and the Keyboard spoke would visually appear exactly identical in the two cases! Because we'd be doing some 'secret behind the scenes' stuff in the 'default layout' case, the behaviour of the installer would no longer be easily predictable based on what the user can see in the UI.

So...I'm no longer confident this is hugely easy to fix, unfortunately. We could fix it anyway and live with the inconsistency that people who manually configured a set of X layouts with US at the top would just get plain 'US' as their console layout, I guess. It's not _horrible_. But I wanted to make sure we think it through in advance...

Comment 29 Adam Williamson 2013-12-13 00:46:13 UTC
dropping f20 fe status as f20 has shipped, adding commonbugs.

Comment 30 Vratislav Podzimek 2014-01-07 14:43:56 UTC
Adam, what do you think about adding some "Use as console keymap" radio button to the keyboard configuration screen? That way we could leave the decision and rewview to users.

I'm thinking about a two-part keyboard configuration screen with an upper part providing keyboard layouts grouped by languages (same way we now provide locales) and a lower part serving as a "shopping cart" for layouts where users could also mark the default/console one, change order etc.

Do you think that could work? CC'ing Máirín to get an expert opinion.

Comment 31 Adam Williamson 2014-01-07 16:37:44 UTC
In technical/code terms I think it's a viable approach, I'm not sure whether Mo would think it's too scary in UI terms. It also raises the question of to what extent we allow people to shoot themselves in the foot - do we let them choose converted X layouts with no ASCII capability as the console layout? I'd say no, but that likely adds some code complexity and possibly some UI complexity.

Comment 32 Fedora End Of Life 2015-05-29 09:56:07 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 33 Fedora End Of Life 2015-06-30 00:45:54 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 34 Adam Williamson 2015-06-30 01:46:37 UTC
We've never done anything to address this AFAIK, re-opening.

Comment 35 Jan Kurik 2015-07-15 14:44:10 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Comment 36 Jens Petersen 2016-01-20 02:30:18 UTC
I believe langtable has data for this too so it should be easy to do.
Probably Mike Fabian can confirm my memory serves me correctly?

Comment 37 Jens Petersen 2016-01-20 02:31:24 UTC
I assume this still applies to F24 Rawhide?

Comment 38 Mike FABIAN 2016-01-21 14:55:28 UTC
(In reply to Jens Petersen from comment #36)
> I believe langtable has data for this too so it should be easy to do.
> Probably Mike Fabian can confirm my memory serves me correctly?

Yes, langtable has data for whether a layout suports ASCII.

Comment 39 Fedora End Of Life 2016-11-24 11:05:03 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 40 Adam Williamson 2016-11-24 22:40:25 UTC
Don't think anyone did anything about this.

Comment 42 Mike FABIAN 2020-07-29 12:05:10 UTC
(In reply to Jens Petersen from comment #36)
> I believe langtable has data for this too so it should be easy to do.
> Probably Mike Fabian can confirm my memory serves me correctly?

Yes, langtable has data for this.

    $ python3
    Python 3.8.3 (default, May 29 2020, 00:00:00)
    [GCC 10.1.1 20200507 (Red Hat 10.1.1-1)] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import langtable
    >>> langtable.supports_ascii('us')
    True
    >>> langtable.supports_ascii('ru')
    False
    >>> langtable.supports_ascii('de(nodeadkeys)')
    True
    >>> langtable.supports_ascii('ge(os)')
    False
    >>> 
    >>> langtable.supports_ascii('foobar')
    True

The last example ('foobar') shows that for keyboard not yet in the langtable data, True is returned, i.e. unknown layouts are assumed to support ASCII.

Maybe I should return None in that case ... 🤔?

Comment 43 Sundeep Anand 2020-08-12 13:12:41 UTC
Somehow this bug is linked with bz1158370 and bz1626901. I guess, this could be achieved in 3/4 steps:

[Step 1] change the keyboard layout ordering to "US, native"; PR https://github.com/rhinstaller/anaconda/pull/2782

[Step 2] create a list of default keyboard layouts (with the help of langtable) as explained in https://bugzilla.redhat.com/show_bug.cgi?id=1626901#c3 and prepend to keyboard layouts for newLayoutStoreSort. or, tweak the sorting (https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/ui/gui/spokes/keyboard.py#L92) a bit.

So, default ones will be top in the order and rest of all shall be after a separator. Hence lesser scroll for users. for example:

>>> from langtable import list_keyboards
>>> list_keyboards(languageId="pt", show_weights=True)
[['br', 600], ['pt', 400]]
>>> list_keyboards(languageId="zh", show_weights=True)
[['cn', 1000]]
>>> list_keyboards(languageId="fr", show_weights=True)
[['fr(oss)', 600], ['ca', 300], ['ch(fr)', 100]]
>>> list_keyboards(languageId="de", show_weights=True)
[['de(nodeadkeys)', 700], ['de(deadacute)', 100], ['at(nodeadkeys)', 50], ['ch', 49], ['be(oss)', 1]]

say for 4 lang_id(s): pt, zh, fr, de -- (presorted - before GtkTreeIterCompareFunc) keyboard layout list would look something like:

'br'
'cn'
'fr(oss)'
'de(nodeadkeys)'
----------------
'pt'
'ca'
'ch(fr)'
'de(deadacute)'
'at(nodeadkeys)'
'ch'
'be(oss)'


Or, a rework/refactor to prepare keyboard layouts list using langtable altogether.

[Step 3] UI redesign. Something on the lines of https://bugzilla.redhat.com/show_bug.cgi?id=1039185#c30 like grouping of layouts by language_id. (with the preference to the selected one) This would need further discussion on what could be the design/ui components/navigation scheme for maintaining fewer clicks and eliminating confusion.


Just wanted to discuss about the approach a bit before moving to step 2.

Comment 44 Sundeep Anand 2020-08-14 12:00:04 UTC
As [Step 1] could suffice this bug; let's continue the discussion on bz1158370.

Comment 45 Sundeep Anand 2020-09-02 10:37:06 UTC
The fix has been shipped with anaconda-34.3-1 built for f34 https://koji.fedoraproject.org/koji/buildinfo?buildID=1604195.

Comment 46 Adam Williamson 2021-01-04 21:34:10 UTC
So sorry that I only noticed this now, but I think the fix for this broke something: it broke the *console* layout configured for the installed system with the relevant languages.

Check the Russian install test from 20200831.n.0 (before this change):
https://openqa.fedoraproject.org/tests/652608#step/disk_guided_encrypted_postinstall/1
and the test from 20200902.n.1 (after this change):
https://openqa.fedoraproject.org/tests/653618#step/disk_guided_encrypted_postinstall/1

That's plymouth handily showing us what console layout is in use during disk decryption. Before this change it was ru, which is correct. After this change it is us, which is not correct.

I've known the Russian install was broken for a couple of months but never got around to figuring out why until now, sorry :(

Comment 47 Adam Williamson 2021-01-04 23:26:33 UTC
Filed https://bugzilla.redhat.com/show_bug.cgi?id=1912609 for the new issue.

Comment 48 Adam Williamson 2021-01-04 23:27:52 UTC
I guess we can close this bug, though, because the change requested here was definitely made. It just broke something else.


Note You need to log in before you can comment on or make changes to this bug.