🚀 go-pugleaf

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.