Date: Thu, 14 Aug 2014 14:21:34 +0200 From: Stefan Esser <se@freebsd.org> To: Ed Maste <emaste@freebsd.org> Cc: "Andrey V. Elsukov" <ae@freebsd.org>, Aleksandr Rybalko <ray@ddteam.net>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Keymap definitions for VT / NEWCONS Message-ID: <53ECA9CE.3070106@freebsd.org> In-Reply-To: <CAPyFy2DY20CJA6zc18%2Beie7%2BAm5UOV3ucu4vbirFhwcxgptttg@mail.gmail.com> References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> <CAPyFy2DMtFhwosD4z4sVHANB3Bp9_kECNrMWHOH=VpJiPyg2aQ@mail.gmail.com> <53EB0DA0.5000305@freebsd.org> <CAPyFy2BsMzvoYdNiYmRb6RTB_=TzDBoCW7PVETchuNirTJ%2BS2g@mail.gmail.com> <53EBEDC8.3080303@freebsd.org> <CAPyFy2DY20CJA6zc18%2Beie7%2BAm5UOV3ucu4vbirFhwcxgptttg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 14.08.2014 um 05:14 schrieb Ed Maste: > On 13 August 2014 18:59, Stefan Esser <se@freebsd.org> wrote: >> >> And I think it is better to use locale names in any case. The >> selection logic has to be there for locales, why complicate >> matters by introducing 2-letter names, which in fact match >> the 2nd half of a locale name when country code and language >> code don't match (as in "en_US.kbd" vs "us.kbd"). >> >> I think we should provide keymap files under the same names >> as the locale names (less the encoding). > > But there isn't a 1:1 mapping between locales and keyboard maps, since > we have to deal with some special cases (like dvorak). We should let > the end user independently choose the language (for interacting with > the installer), keymap, and locale anyway, even though in most cases > there is a straightforward mapping between them. So I don't think it > makes much difference if we have a keymap called fr.kbd for example, > or a different name. There probably won't be a 1:1 mapping for all cases, but I think that there is value in going for a regular naming scheme. We can use "fr.kbd" as a short form of "fr_FR.kbd", but there will be a "fr_CH.kbd" and possibly a "fr_CA.kbd". The "fr" in the short form will correspond to the "FR" in "fr_FR.kbd", which is hidden by the fact, that both parts read "fr". But look at "uk_UA.kbd", which will be short-named as "ua.kbd", or "be_BY.kbd" mapped to "by.kbd" versus "nl_BE.kbd" mapped to "be.kbd". For some language/country combinations, the short form ends up in a distant location to the long form names. And will there be a "ch.kbd" for "de_CH.kbd" (the majority of Swiss users will use that keymap), or will they all be of the form "??_CH.kbd" ... ??? For all these reasons I think the short form serves no real purpose. If you want to support it, you could symlink a short name to the locale based name (to allow the use of just the country code, if people edit rc.conf by hand, while I'd expect the installer to use the locale based keyboard names). >> We'll need a mapping file (like "INDEX.keymaps" for syscons), >> I assume. > > I wouldn't necessarily call INDEX.keymaps a mapping file; it's just > used for the menu-driven keymap selection. I think we can use the > exact same scheme and file format for vt(4). Yes, I know its purpose and I agree, that the format should be usable for NEWCONS keymaps, too. We'd just need to teach it about the two supported drivers and make it select the correct path for SYSCONS vs. NEWCONS (based on the sysctl). I think this should be implemented in time for 10.1, if at all possible. Changes required are: - Selection of NEWCONS/SYSCONS pathes and defaults: * DEFAULT_KEYMAP_DIR * DEFAULT_FONT_DIR * DEFAULT_FONT * DEFAULT_LANG We may want to introduce a new rc.conf variable for NEWCONS, since the format has changed (e.g. no ".iso." in names). That way, a mapping script could suggest a suitable keymap for NEWCONS, if running under NEWCONS and only a SYSCONS keymap has been defined. And that way, you could reboot into SYSCONS in case of problems with NEWCONS and still have your SYSCONS keymap defined (under the old rc.conf variable name). >> The keymap names are not consistent, as it is now. If we agree, >> that names without ".acc." are "nodeadkey" variants and with >> ".acc." have dead keys for accents and the like, then for some >> locales the ".acc." version will be "normal" and expected by >> users, while its the plain version for other locales. > > Are you proposing that we have a combination of *.kbd, *.acc.kbd, and > *.nodeadkey.kbd variants, depending on which type is the common / > expected case for various layouts? I'd think it was best, if we had a common keymap under the name of the locale (e.g. "en_US.kbd"). This keymap should work as expected by users, which in case of e.g. the German keyboard means, that a few accents are deadkeys, while most keys are of the "nodeadkeys" variant. E.g. ^ on my keyboard is used as an accent and needs a blank typed after it to appear on its own, while ~ is not considered an accent, but a "normal" character. (And ´ and ` are accents, while ° and ' are characters.) On the Swiss-German keymap, other characters are expected to work as accents or just as characters. A nodeadkeys variant makes no sense in Switzerland, while it might be of use in Germany (where the accents are only used to write foreign names and the like). >> That's why I suggested to follow some other system (e.g. Windows) >> use of accent keys / dead keys. Users in the respective locales >> will know and expect the keyboard to behave just this way. > > I think it's important to make a distinction between the way the user > selects a keymap, and the filename. In the common case I think users > will choose a layout from a menu, and won't necessarily see or care > about the filename. I'm not sure what contemporary Windows versions > do with respect to keyboard selection - can you describe the process > it uses? The selection is automatic when you install windows. You'll be asked for the language and the country, and while not being displayed, the selection of the keyboard follows the locale selection. You can switch keyboards, e.g. on a Swiss notebook between de_CH and fr_CH. But the keyboard selection tool does not show the locale in that form, instead it only shows the language part (assuming that the country is known). Staying with the example of the Swiss notebook, I get the choice between "DE" and "FR" keyboards. Only if I select the option to also display text labels, these two variants are named "DE Deutsch (Schweiz)" and "FR Französisch (Schweiz)" (the output locale is "German" in both cases, leading to the display of "Französisch" instead of a locale description in French). If you want to add an alternate keyboard layout, your choices are sorted by language, not by country. E.g. on above mentioned Swiss notebook, invoking the "Add Language" option of the keyboard selection utility places me in the scroll area on "Deutsch (Schweiz)" with "Deutsch (Östereich)" above and "Divehi (Malediven)" below ... I'd have thought, that the sorting by country and then by language was more reasonable, but the list is sorted in the same way as in the MS-Office language option for the spell- checker, for example. This Windows tool provides a similar function our language selection tool. After selecting a locale (language,country), a button list is displayed, which allows to select between one or more layouts for that locale. In the case of "English (USA)" the layouts start with "English (USA, Dvorak, left-handed)" and "English (USA, Dvorak, right-handed)" and continue to "English (USA, international)" and "US". There is no choice of deadkeys vs. nodeadkeys variant for any of the keymaps I looked at, but there appear to be variants with regard to "Shift-Lock" or "Caps-Lock" for a few locales. And there are further specialties, like "Spanish" which exists in "international" and "traditional" layouts. This all looks very similar to a tuple of language and country (while locales are country_LANGUAGE) with optional modifiers for specific layouts (like our ".dvorak." in keymap names). >> And it is really annoying to see my efforts wasted! :( > > I don't think any of your effort is wasted -- my commit was just an > svn copy of the 8 trivial kbd files, as I thought you were working > only on the keymap files needing conversion for Unicode. Anyhow, > changing the naming scheme (if we want to do that) isn't a big deal. > We'd have to deal with pl.kbd and ua.kbd already. Sorry, it was late at night and I really have spent quite some time on the conversion of keymap files. Your commits do no harm, although I had prefered to have agreement on the naming of keymap files. And I still strongly prefer names that are identical to locale names, wherever possible. Most users will either use the installer (and will thus never see the locale IDs), or they'll manually edit rc.conf and will know their way. And then it's easier to mechanically put the locale ID in to the keyboard selection variable, instead of thinking about (or looking up) whether this is a country that does not need the full locale ID to select a keymap. In Europe, you'll often need the locale name, not only the country. If you really think that the 2-character ISO country codes should be available as a short-hand, than I'd really want to install the keymap under the locale name and only add a symlink from the country name. Regarding the files you committed: I had edited all files, including those that do not generate different codes when converted to Unicode, at least in so far as I have removed misleading comments (e.g. claiming that the encoding was ISO5589-*, when Unicode is now universally used). I really think we'll regret using anything but locale names for keymaps, and I'd want to rename those that you committed under 2-letter ISO names. Is that acceptable to you? Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53ECA9CE.3070106>