Re: x5250 update

On Thu, 3 Jun 2004, Scott Klement wrote:

> There are a number of other options as well.  I'd hate to think that it's
> necessary to hard-code all of the ones that will have to be handled
> specially.

Hmm... the ones I mentioned are the only ones that show up in the help.

> getopt_long() does work, but it's NetBSD's implementation, not GNU's.
> There's a listing of the differences between them on the following page:
>
>    http://www.freebsd.org/cgi/man.cgi?query=getopt_long

Ok, I'll look at this and make sure it works for both platforms.

> Now that I've gotten it to compile, I see that you're overriding lib5250's
> keyboard handling?   If I type a key in a field that's supposed to be
> uppercase-only, it shows up as lowercase then converts to uppercase when I
> hit enter.

Actually, I'm not overriding it.  Right now I'm working on the problem of
redrawing the screen.  Here's what happens:

1. You press a key.  Xlib gets the keypress event and reports the event
back to x5250.

2. x5250 finds out what key was pressed from Xlib.  x5250 returns the
result to lib5250.  At this point x5250 knows what key was pressed and
remembers it.

3. lib5250 processes the key stroke given it by x5250.  Then it calls
x5250_terminal_update().

4. Currently, in order to minimize calls to the Xlib drawing functions,
x5250 only redraws the screen if the key stroke cause either network
activity to occur (Tn5250Terminal->conn_fd has pending data) or when the
keyevent occurred x5250 set a force update flag (currently set on field
plus, field minus, and field exit).

5. If the screen isn't redrawn due to one of those conditions, x5250
simply draws the key that it already had to figure out when the keyevent
was originally received.  This makes sense (if you ignore what lib5250
does to the characters) because x5250 already knows where to put the
character and what character to put there.

What should be done is that x5250 should remember where the cursor was and
ask lib5250 what character should be drawn in just that place.  That way
we don't have to run through the loop of the whole screen to find the one
character that changed and we also get the correct output on the screen.
Fewer drawing requests and the correct output :)  This particular fix is
in the works.

> I can type letters in numeric fields -- although it stops me after the
> first letter...   then error reset doesn't work, you have to hit Ctrl-R
> instead of error reset -- and then it doesn't clear the message line, so
> you have to just know that pressing ctrl-r worked, despite that error
> reset didn't. :)

The error reset key (as mapped for xt5250 or tn5250) doesn't exist in
x5250 because x5250 is neither an xterm nor a console.  x5250 receives the
raw key presses as events.  This has some advantages (no messing with
termcap/terminfo) and some disadvantages (we need a method for
keymapping).  Fortunately, Xlib provides a way to get user defaults so we
have a method for specifying on a per-user and site-wide basis what keys
should do what.  But it won't involve XTerm since x5250 isn't an xterm.  I
have some cool ideas on how to let the user change key mapping on the fly
and then save those changes using Xlib's user defaults support.

As far as the message line goes, the standard message line that contains
"X SYSTEM" or "X II" hasn't been implemented yet.  What you do have at
this point is a changing mouse cursor:  when input is inhibited the mouse
cursor changes to an X.  Of course the standard message line will also be
implemented, and the mouse cursor changing will be selected by a user
default.  The lack of this message line is also why the message waiting
indicator does not show up but instead prints "message waiting" to stdout.
This message line shouldn't be hard to do, it's just not there yet.  btw -
the message line that actual messages show up on is there and does work, I
refer only to the lowest line of xt5250 that has the cursor position on it
and shows such indicators as message waiting, system busy, or system wait.

Another note:  in my tree I have the left mouse button work as the reset
key.  Certainly not for everyone, but I think it is a great feature.  I
was talking with some other people about it and they mentioned the idea of
clicking on the "X II" part of the indicator line (once implemented) to
reset.  And clicking on "MSG" to see the waiting message.

> Can I ask why you rewrote that section of display.c/dbuffer.c instead of
> using the tried-and-true code?  Why reinvent the wheel?!   If there was
> something lacking in lib5250, why not help improve it instead of replacing
> it?

I didn't rewrite it and x5250 uses that code unmodified by standard
lib5250 calls.

> I also see that you're using the GPL.  The GPL is incompatible with
> OpenSSL, so the rest of TN5250 uses the LGPL.  If you use GPL, we won't be
> able to distribute x5250 together with lib5250 -- just a warning.

Hmm... I'll have to think about this.

James Rich

Vs lbh guvax bs argjbex frphevgl nf na vzzhar flfgrz, Jvaqbjf vf UVI.
        -- Wbr Cyhgn