Re: Re xt5250 and 132 column issues....

Hi Fred,

> This is where I experience about a 3 – 5 second wait before the 132
> column screen is displayed, but with only 84 columns and 25 rows. The
> rest is cut-off.

I run FreeBSD, and have not encountered this symptom.  However, I can 
explain to you how things work, and maybe that'll give you some ideas of 
how to solve the problem.

xt5250 is really just the tn5250 program running in an xterm.  tn5250 
detects that it's running in an xterm by checking the TERM environment 
variable.  If it's set to "xterm", "xterm-5250" or "xterm-color", it 
assumes it's in an xterm.

The FreeBSD port (/usr/ports/net/tn5250) for TN5250 does not install the 
xterm-5250 termcap entry for you -- so if you built from ports, you'll 
need to install it manually.  The code for the termcap entry should be 
copied to /usr/local/share/tn5250/sample.termcap -- you'll want to 
install that for best results.  Though, as a workaround, you can just 
edit the xt5250 script and change the terminal type to "xterm" instead 
of "xterm-5250".

When running in an xterm, tn5250 will send an escape sequence (ESC ] 50; 
<fontspec> \x07) to the xterm when the screen size has changed.  This is 
what the font_80 and font_132 options are for... when switching to a 132 
column screen, the string you have in font_132 will be used for 
<fontspec>.  When switching to an 80 column screen, the font_80 string 
will be used for <fontspec>

After that, TN5250 sends "ESC [8;<hh>;<ww>t" to the xterm.  Replace <hh> 
with the new height of the screen, and <ww> with the new width of the 
screen.  It sends it to xterm to tell xterm to resize to the new 
height/width.  Theoretically, xterm should resize itself to have 132 
columns and 27 rows (or 80x24, if switching to that screen size)

Finally, it raises SIGWINCH to tell xterm to activate the new settings. 
  Theoretically, that should happen immediately and life should be good. 
  Early on in the development, though, we discovered that the screen 
size might not happen synchronously, so we had to invent a way to wait 
until the screen size changed...   so we added code to call getmaxyx() 
from ncurses and see what the width of the screen is currently set to. 
If it's it's not set to 132 (after we just sent the escape code to tell 
it to be 132) we'll call the refresh() API from ncurses in a loop until 
the terminal catches up and resizes the window correctly.  Each time it 
gives us the old screen size, we do a usleep(10000) (1/10 second wait) 
to keep tn5250 from sitting in a tight loop.  We will only attempt this 
10 times before giving up.

I suspect that the delay is caused by the fact that you've maximized it! 
   As a maximized screen, I suspect that xterm is ignoring the escape 
sequence asking to resize the screen, and therefore it'll never change 
to 132 columns... tn5250 will sit and wait for the timeout, thus the 
delay you're experiencing.

I don't know why you'd only see 84 columns... all I can guess is that 
you've picked a font that's too large to fit all 132 columns on the 
screen...  is that possible?

xt5250 was not designed to be used in a maximized window. You realize 
that maximizing the window doesn't change the font size, or the number 
of rows/columns, right?  So what's the point of maximizing it?   You'd 
just end up with large black spaces on the screen that can't ever be 
used...

It's important to understand that xt5250 is just tn5250 running in an 
xterm.  We didn't write xterm, and have only minimal control on how 
xterm works.  We can send it escape sequences, we can't force it to use 
them.  There's a lot of other stuff that we have no control over at all. 
  If you want this to behave as a normal "Windows" program would behave, 
then xt5250 is probably not the right tool for you.

> At this point, if I miimize the window, all 132 columns and 27 rows are
> displayed. I can then maximize again, and everything is fine from here on
> in, for the rest of this xt5250 session.

I don't think you really mean "minimize" here.  You are probably just 
restoring the screen to it's normal mode.  (If you minimize it, you 
can't see the screen...)  That makes perfect sense, when you return to a 
normal window (instead of a maximized one)  xt5250 would function as 
designed.  When you maximize again, xt5250 loses it's ability to control 
the screen, but that's irrelevant since it's already set up the way you 
want it.

> About the 3 –5 second wait: I don’t see this as being a problem on our
> iSeries , or on the network. None of our Client Access PC’s exhibit this
> wait. Also note that it is a one time thing, when entering that first 132
> column screen.

Hmmm.. I don't know why it would only happen the first time (unless you 
stay in 132 column mode thereafter -- in which case it's only doing it 
once.)

You're right though, the problem is definitely on your FreeBSD desktop. 
  The question is whether it's in X.Org's xterm, or the FreeBSD video 
driver, or the tn5250 software.

I use FreeBSD and have not experienced this problem -- but then, I don't 
try to maximize my screen!


> I’ve tested this on an IBM Desktop PC and a Toshiba Laptop with GNOME,
> KDE, Fluxbox and just plain old XDM. The problem existsin the first three
> Desktop Environments, but not in XDM. Probably because there is no option
> to Maximize the xterm in XDM.

XDM??  Huh?  Do you mean TWM?  (XDM is really just a sign-on screen... 
it's not a desktop environment)

I'm running FreeBSD, and have not encountered the problems you describe. 
  However, I have not yet upgraded to 7.0 -- and I don't maximize my window.

Have you tried x5250?  You might have better luck with that.  x5250 is a 
true X11 program, it's not a console program running in an xterm.  If my 
theories are correct, that SHOULD make a big difference.

-- 
This is the Linux 5250 Development Project (LINUX5250) mailing list
To post a message email: LINUX5250-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/linux5250
or email: LINUX5250-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/linux5250.