RE: Full screen mode

On Wed, 5 Sep 2001, Sean Porterfield wrote:
>
> I had just noticed the same problem the other day (I haven't used tn5250 in
> a while).  It seems to happen more on a slower connection (I'm coming in
> over the Internet instead of on the LAN).

Hmmm...  that strikes me as odd, since it's not waiting for any data to
be send/received over the network at that point.  It already has the data
in it's buffer, it just needs to wait for the screen to actually resize
so that it can draw all of the data...

What is doing at that point is that tn5250 is telling curses to resize the
screen by calling the resizeterm() function.  It is also sending an escape
sequence to xterm telling it to change it's dimensions, and finally it's
sending the "SIGWINCH" signal to itself.   I don't really understand
that last part, since the way I understand it is that xterm should be
sending the SIGWINCH to us, not the other way around, but I'm certainly
no expert.   (I should probably play with that a little more)

The _problem_ is that after doing all of these things, ncurses is still
telling us (at least for a few milliseconds) that the width of the screen
is still 80.  Therefore, tn5250 only redraws the screen out to column
80 -- even though we've already told it that we need 132.

What my patch does is it attempts to wait until ncurses has realized
that the screen has resized to 132 before redrawing the screen.  It
only tries 10 times, so if for some reason ncurses is refusing to
resize the screen, it won't hang there forever.

>
> Would you classify this fix as a kludge or a real fix?  (It does actually
> solve the problem.)  I'm no C guru (I can barely read the language) but it
> appears you're checking to see if the window is the size it's supposed to
> be, and if not, waiting and checking again.  Is that essentially correct?
> (What is the unit of measure for usleep?  microseconds?)

Yes, usleep() sleeps for a quantity of microseconds.

I would definitely consider this a "kludge" not a real fix.   There MUST
be a better way -- some way that we can tell ncurses not to return from
the resizeterm() function until it's done resizing -- or a way to tell it
to signal us directly, so we don't have to poll the results...

I suppose I should really do a more in-depth analysis of the problem...
try to determine if it's ncurses or xterm that's causing the delay and
see if I can determine a better way to wait for the result.   The patch
that I posted was just something I threw together quickly one day...

I guess I'm hoping that someone who understands this stuff a little better
will see my patch and tell me what the magic fix is -- saving me the
trial & error... :)

>
> Thanks Scott!  I love the shift left and shift right too.  I didn't even
> know CA could do that until someone mentioned it here.  My XTerm didn't
> update from CVS, so I just added the two lines manually...
>

Good... I'm glad people are finding this stuff useful :)