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.
midrange.com
