Date: Thu, 14 Aug 2014 00:59:20 +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 Subject: Re: Keymap definitions for VT / NEWCONS Message-ID: <53EBEDC8.3080303@freebsd.org> In-Reply-To: <CAPyFy2BsMzvoYdNiYmRb6RTB_=TzDBoCW7PVETchuNirTJ%2BS2g@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 13.08.2014 um 22:31 schrieb Ed Maste: > On 13 August 2014 03:02, Stefan Esser <se@freebsd.org> wrote: >> >> I have renamed the files to 2-character ISO country code names, and >> have used the form "fr_CH.kbd" (instead of "swisscfrench.iso.kbd") >> where there are several locales within a country. > > This sounds good to me. > >> Unresolved: >> >> - Shall keymap names for countries where language and country are >> identical (e.g. "pt.kbd") be converted to "pt_PT.kbd"? >> (I'd say yes ...) > > We already had ua.kbd and pl.kbd and I just now brought over the > ??.iso.kbd files before catching up on this thread. It seems :( :( I had announced that I was waiting for feedback until Thursday before I wanted to commit what I have prepared. I have spent many hours converting keymaps (not only the trivial ones, which are identical in ISO8859-1 and UTF-8), and I'm really annoyed! > reasonable to me to use only the language code unless we need to be > more specific. I wanted to have consensus on this before we start committing keymap files. 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). We'll need a mapping file (like "INDEX.keymaps" for syscons), I assume. But I'm not sure about all these points ... >> - In the example of Switzerland, "swissgerman.kbd" becomes "de_CH.kbd". > > Sounds good to me. > >> * Do we want to add "ch.kbd", too? >> * Should it be a symlink to one of the other keymap files (the >> majority of the Swiss population would use de_CH, I guess) > ... >> That would imply, that for every locale selected by a user, there >> is a matching default keyboard. > > I wouldn't worry about this unless there's a precedent in X11 or the > Linux console. Well, I do not think that a locale is complete without a keymap, even though these are completely independent parts of the system (locale handling vs. keymaps). But I'd expect that a keymap exists, if a locale is supported and vice versa. >> And after all these normalizations have been performed: >> >> - How do we deal with accented versions of keymaps? >> (Those with ".acc." in their names ...) > > I think we can just bring them over as ??.acc.kbd once we've verified > they work as expected. 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. 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. Special keyboards (e.g. Dvorak layouts) do obviously need special keymap files (with .dvorak. inserted). But for the typical PC keyboard used today, I'd hope for the same behaviour as under Windows (not claiming that it is correct, just that it is expected). >> - Do we keep all those variants that only differe in the handling >> of the Caps-Lock key (which often is mapped to an additional >> Control key)? > > I don't see why not. > > Oh, one other point: I'll add a stripped-down share/vt/INDEX.keymaps > shortly, and we can add new entries there as we bring the keymaps > over. We'll also need UTF-8 encoded translations of the names. I really want to have a concept on what the keymap names shall be and how they are selected (in rc.conf and in the installer). And it is really annoying to see my efforts wasted! :( STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53EBEDC8.3080303>