GNOME Bugzilla – Bug 650128
Keyboard layout indicator does not distinguish between variants of the same language.
Last modified: 2011-08-26 14:53:44 UTC
I use the Dvorak variant of the GB keyboard layout, but for obvious reasons have the regular GB keyboard layout configured as my second choice. In GNOME 2, the panel applet showed “GBr” when I was using Dvorak (my default layout); when I hit the keyboard shortcut to switch to Qwerty (or chose it from the menu), the panel applet showed “GBr₂”. In GNOME 3, the keyboard status indicator shows “GBr” regardless of which layout is in use. While this is technically correct—they are both Great British keyboard layouts!—it is a regression on GNOME 2's behaviour. The menu displayed when I click it displays the two layouts as follows: • Dvorak GBr United Kingdom GBr I assume that the GNOME 2 applet contained code to append subscript numerals to disambiguate keyboard layouts whose short description was identical. So I propose to make _sync_config in js/ui/status/keyboard.js iterate across short_names and disambiguate any duplicate names it encounters in the same way.
Created attachment 187859 [details] [review] KeyboardStatus: disambiguate duplicate short descriptions If two layouts have the same short description (for example, english (US) and english (dvorak)), add a subscript for disambiguating among them.
Review of attachment 187859 [details] [review]: ::: js/ui/status/keyboard.js @@ +92,3 @@ + cnt++; + // U+2081 SUBSCRIPT ONE + for (let i = 0; i < names.length; i++) { The pedant in me wants to point out that U+208F is not a valid code point. The pragmatist in me thinks it's unlikely that anyone will have 15 layouts with the same short name. :þ
(In reply to comment #2) > Review of attachment 187859 [details] [review]: > > ::: js/ui/status/keyboard.js > @@ +92,3 @@ > + cnt++; > + // U+2081 SUBSCRIPT ONE > + for (let i = 0; i < names.length; i++) { > > The pedant in me wants to point out that U+208F is not a valid code point. > > The pragmatist in me thinks it's unlikely that anyone will have 15 layouts with > the same short name. :þ As the comment says, Xorg enforces a global limit of 4 layouts.
I didn't understand where the ≤4 limit came from: I'd interpreted it as an estimated reasonable upper bound. :)
To me, the bug is in the keyboard data. If I have a Russian keyboard and the Dvorak variant of GB installed, then it's perfectly fine if the indicator shows: Rus Dvr So the keyboard data should simply report a short name of Dvr or whatever rather than Gbr for Dvorak variants. For the short indicators, we should ask ourselves two questions: - Is it meaningful to the user? - yes, if you selected a Dvorak layout, you know what Dvorak is. - is it good for distinguishing the layout from other layouts that the user might be using at the same time. To me, having multiple Dvorak layouts installed at the same time is corner case and weird, while having Dvorak and non-Dvorak is sort of useful if you want to let other people type on your computer, so the distinguishing thing about this layout variant is not that it's a layout for Great Britain, but it's a Dvorak keyboard. Can someone take care of filing this in bugs.freedesktop.org? [ Note that having some fallback way of distinguishing layouts if the user does a strange combination of keyboard layouts is still probably slightly useful, so the patch might be right without regard to the fact that the real bug is in the keyboard data. ]
Owen, the current approach is to use language codes in the indicator. So (after last fix), there is no GBr - there is "en". Also, there never was "Dvr" - there is "en" as well. Are you saying that we should make all shortDescription tags unique even within the same language? Should layout 'us' be distinguishable from 'gb' (they have the same shortDescription)? And from us(intl)?
Same here, I use two Ltu variants: Ltu with US numbers and LEKPa, but indicator for both shows only Ltu, so there is no way to distinguish which is currently active. I was thinking how to show what keyboard layout is currently active, and I see one solution: each keyboard should provide several short descriptions (three letters), first would be used be default, and two alternate short names would be used if there is already a short name with same name in list of all keyboard layouts selected by user. For example: * Ltu (primary), LUS (alternate 1), LTS (alternate 2) * Lkp (primary), Lek (alternate 1), Lka (alternate 2) And if now indicator would show Ltu and Lkp for me, it would be clear what keyboard layout is currently in use.
(In reply to comment #5) > To me, the bug is in the keyboard data. Maybe, or maybe not (3 chars are just not enough to express all possible keyboard layouts, and the user should be free to pick his favorite combination). In any case, should the shell disambiguate? That is, is the patch good?
From my POV it looks correct.
I think, that keyboard layout short names, should be added upstream, so desktop environments just could use standard solution, instead reinventing this again and again. See this bug report: https://bugs.freedesktop.org/show_bug.cgi?id=37827
Currently, the indicator follows the GNOME idea about displaying the _language_. See http://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/InputLanguage So, first of all, it is all lowercase, second - it must be short enough, 2 letters ("Each option will have a two character ID field"). Adding the index, like it was in 2.32 and what Giovanni implemented, seems to me like a reasonable compromise. Otherwise we'd have to ensure that every variant has globally unique short description of 3-4 letters. FYI information, there are already ~500 variants.
(In reply to comment #11) > So, first of all, it is all lowercase, second - it must be short enough, 2 > Adding the index, like it was in 2.32 and what Giovanni implemented, seems to > me like a reasonable compromise. Otherwise we'd have to ensure that every > variant has globally unique short description of 3-4 letters. I use two keyboard layouts, both from same language, lt-us and lt-lekpa. If I understood correctly, you suggest, that in my case, keyboard layout would be displayed like this: lt1, lt2. Or: lt, ltz. For me, lt1 and lt2 names, still hard to distinguish, which is lt-us, and which lt-lekpa... But if those layouts would be displayed as: ltu, lkp, it is clear enough, which is which. Same in situation, described above: Gbr, Dvr. I just want to suggest, that adding index to language code, does not solve problem it just makes this problem little less annoying... Each user uses I guess 2 to 5 layouts, so using several short name aliases for one layout variant you can always get unique list.
> Each user uses I guess 2 to 5 layouts, so using several short name aliases for one layout variant you can always get unique list. I guess most of the users use 1 national layout. Most of the people using 2-4 layouts (you cannot use 5) use layouts for different languages. So, I would not overestimate the number of people who use different layouts for the same language. I absolutely and decisively dislike the idea of having multiple short descriptions. Maintaining such a mess would be a royal PITA. There is one shortDescription per layout/variant, that's it. I would like to hear the opinion of somebody from the gnome usability squad.
I would strongly favor keeping the short (en, de, it) language ids for the common case of no conflict. If the conflicting case mainly arises for Dvorak variants, and we can identify Dvorak layouts somehow based on their keyboard-config data, then we could just add '(Dvorak)' to disambiguate. Absent any other discriminators, adding numeric subscripts is certainly better than nothing.
I can propose adding custom labels to gsettings - in that case everyone is free to use whatever strings he likes. But no exposure in GUI - only gsettings (for people who can google or read the source code:)
(actually, custom labels were implemented as plugin back in 2.32 days)
Judging from the previous comments this bug is well understood by the developers, but since the state is "unconfirmed" I'd like to add that I've experienced the problem as well. In my case I switch between "English (Dvorak)" and "English (US)" which results in identical short names "en" and "en". I came up with my own patch prior to discovering this bug, but there is no need for me to attach it since it would just add more confusion given the existing patch. I think the patch should be applied since otherwise there is no visual indication that the layout has changed. One other thought - if for some reason it's decided that the short names should not be altered to make them unique perhaps some animation should be displayed when the switch happens so the user knows it happened.
juste as Steven E. "Judging from the previous comments this bug is well understood by the developers, but since the state is "unconfirmed" I'd like to add that I've experienced the problem as well." I use bépo (kinda dvorak) variant for fr keyboard. It’s a family computer (mainly azerty fr layout), and it’s a bit annoying that "fr" is always displayed. So somehow, I confirm the "bug".
(In reply to comment #17) > Judging from the previous comments this bug is well understood by the > developers, but since the state is "unconfirmed" I'd like to add that I've > experienced the problem as well. In reply to comment #18) > juste as Steven E. "Judging from the previous comments this bug is well > understood by the developers, but since the state is "unconfirmed" I'd like to > add that I've experienced the problem as well." We do not use the "UNCONFIRMED" and means exactly the same thing as "NEW" to us.
So, we have a patch that resolves the problem. Xkeyboard-config was updated with better layout/variant descriptions. So, if we apply that patch to gnome-shell, would anybody get angry? Would that close the bug?
If anybody wants to know what should have been done, please read comment 5. This is a bug in the xkeyboard-config data. If it has the same shortDescription for the US layout, and the Dvorak US layout, we *CANNOT* show anything meaningful to the user to distinguish them. So, the short description for all Dvorak layouts should be changed to dv. This actually will be meaningful to users, while en₁ en₂ will not be meaningful, and are also quite visually hard to distinguish at a glance because the only distinction is the small subscript. That being said, this patch is a minor improvement, and if xkeyboard-config is some day fixed, won't hurt things.
Review of attachment 187859 [details] [review]: Makes things better anyways
Attachment 187859 [details] pushed as f99b4da - KeyboardStatus: disambiguate duplicate short descriptions