Re: Re: TN5250 0.16.2 released! -- LINUX5250

I'm afraid that I don't know much about Client Access' .kmp files...
CA has always been a "pay extra" feature, and my company decided long
ago to buy Rumba from Wall Data instead of Client Access...   (I used to
have a 70 day free trial of CA, but alas it has expired)

The keyboard issues on Linux, FreeBSD, etc are a bit more complicated than
those under Windows, however.   Unix is designed to be a server for
terminals, just as the AS/400 is.

The "Console Mode" programs read the keyboard as if it's a connected
terminal.   As do the "xterm" versions of the emulator.   So, you've got 3
aspects to the mapping (where Windows only has one):

   1) What character sequence is sent by the terminal when a key is
        pressed (or IF a sequence is sent!)
   2) What key sequences are recognized by the system and sent to tn5250
        as which "terminal capabilities"
   3) What "terminal capabilities" are interpreted by tn5250 as which
        5250-specific keys.

Reading keystrokes directly from the keyboard, as Windows does, is not
(IMHO) a good idea.   It'll make it much harder to make tn5250 work on
multiple OSes.  It'll make it impossible to use tn5250 from a dumb
terminal or telnet session from another PC....

Using the routines provided by X to read the keystrokes directly is a MUCH
better idea.  Then X worries about the cross-platform issues for us.  In
fact the (unfinished) GTK/Gnome version of the emulator solves these
problems for us!   It sure would be nice if it were finished...   Of
course, that doesn't help those poor souls using "console mode".
(or dumb terminals, or telnetted in, etc)

Perhaps a half-way measure is in order?   Allow Tn5250 to read arbitrary
key sequences and interpret them as arbitrary keystrokes?  Maybe have a
program that the end-user could run where it would say "press the key
you want to use for XXX" and then the program would read whatever the user
typed as the key sequence for XXX?

That wouldn't solve all instances, because not all terminal definitions
send unique values for all of the needed keys...   but it'd solve some of
the situations....

Sigh...  I wish there were a better way....



On Mon, 27 Aug 2001, James Rich wrote:

> On Mon, 27 Aug 2001, tonyl wrote:
>
> > Here's a wish list request:
> >
> > import client access's .kmp (keyboard map) files.
>
> Here is vote to *not* import those files.  tn5250 by and large doesn't run
> on windows machines so why waste time trying to import files created on
> windows machines?  Why should we mimic the IBM way?  I'm sure that there
> are easier ways to handle key-mapping on UNIX machines than trying to
> import Client Access files (even though those files would just tell us how
> the map should be set up).  Just save the map as <insert your favorite
> text file format here - .Xresources format ain't too bad, use XML if you
> want>.
>
> Or don't even worry about keyboard mapping.  Here I've been using tn5250
> since it's initial release (back when I could read all the code and
> understand it in a few hours - and port it to a new arch :) and I don't
> have any problems about how the keys are setup.  Why confuse people by
> trying to make the right control be the enter key?  Just use the key
> labeled 'Enter' as the enter key.  Makes it a lot easier when giving
> support over the phone and you say "Press enter" and you actually mean to
> press the enter key.  Yes we could go fancy with keyboard mapping - but
> should we?
>
> James Rich
> james@eaerich.com
>