jmg@cernvax.UUCP (jmg) (06/05/87)
Since I get and test lots of PD software I see some of the problems which
could be avoided by better software and an understanding of a basic
difference between European and US STs. As well as having a different
keyboard, including use of the <Alternate> key, they have an extra key
(between the left hand shift key and the first alphabetic key {Y or Z}).
Therefore, they have a different numbering of the keys (the number comes
in the 32 bit Bconin value).
I have recently tried out the Gulam shell, as well as the ue.tos included
with it. Both seem hard-wired to the US keyboard, which I assume is
because they translate the key number into a character. This makes it
slightly hard to work with them!!!!
Some products include a keyboard mapping program (e.g. UniTerm), which
is fine. However, even then there can be problems when one needs to
enter <Control> + character.
A doubly complicated problem is use of characters requiring the <Alternate>
key, when combined with the <Control> key. For instance, on a standard
German keyboard the '[' character is entered with <Alternate>. However,
it is then impossible to enter the <Control> [ required for either
telnet escape or to map VT220 control sequences on the UniTerm function
keys).
I am told that the latest version of Magic Sac has hard-coded versions
for the various European keyboards. However, if you then try to use the
Macintosh localiser you again see the keyboard numbering problem (the
lower set of keys seem shifted by one). Thus it looks as if the Magic Sac
is also hung up on key numbers.
Please, folks, if you do write software that uses direct key numbers,
rather than the apparent key code, then allow for the fact that one may
even need a key number mapping. Also, don't forget users of keyboards
where certain characters need the Alternate key.ljdickey@water.UUCP (06/11/87)
In article <490@cernvax.UUCP> jmg@cernvax.UUCP () writes: > ... >difference between European and US STs. As well as having a different >keyboard, including use of the <Alternate> key, they have an extra key >(between the left hand shift key and the first alphabetic key {Y or Z}). > >I have recently tried out the Gulam shell, as well as the ue.tos included >with it. Both seem hard-wired to the US keyboard ... ... >Please, folks, if you do write software that uses direct key numbers, >rather than the apparent key code, then allow for the fact that one may >even need a key number mapping. Also, don't forget users of keyboards >where certain characters need the Alternate key. I assume that direct key numbers were used for good reason (speed?). In reading through this article, it occured to me that there might be a solution open Gulam, namely, for the user to supply to Gulam a table that specifies alterations to the keyboard table. No supplied table, (the default), would mean no alterations to the keyboard mapping. I imagine a table with several rows, each row indicating that the meaning of a keystroke, or keystroke combination, is to be changed. For instance, some volks who are used to typewriters which have the "z" and "y" interchanged (from the way I am used to seeing them). could supply a little table with two rows to correct this problem. People who want to study ergonomics, and experiment and study different other keyboard layouts would love this. I am sure that some would like to use the Dvorak layout.