Re: ripoffline() behavior with resizable windows

[Thomas Dickey]

On Mon, Oct 02, 2023 at 05:09:50PM -0400, Bill Gray wrote:
> Hi Thomas,  all,
> 
> On 10/2/23 04:08, Thomas Dickey wrote:
> > but the documentation for ripoffline doesn't directly mention soft-keys,
> 
>    Hmmm... I made the connection based on :
> 
> https://invisible-island.net/ncurses/man/curs_kernel.3x.html
> 
>     "...The ripoffline routine  provides access to the same
>    facility  that slk_init  [see  curs_slk(3x)] uses to reduce
>    the size of the screen."
> 
>    Supporting this is the fact that if you have SLK plus four ripped-off 
> lines,  such as
> 
> ./ripoff s1 b b t b
> 
>    ("set up SLK,  rip two lines off the bottom,  one from the top,  and 
> another from the bottom"),  it works.  Add another t or b,  and you get the 
> "Only five lines can be ripped off" error message.  Try it again without the 
> 's1' (with just five ripped-off lines),  and it works... it really looks as 
> if the SLK line is considered as one of the ripped-off lines.
> 
>    (Interestingly,  if you use s3 -- the format with an index line added -- 
> it appears to count as only one ripped-off line.  Presumably,  there's just 
> one window created that is two lines high.)
> 
> > and is explicit that it's called only once.
> 
>    I was afraid of that,  but wasn't too clear on it from the text cited 
> above.
> > > https://www.projectpluto.com/temp/ripoff.c
> > > 
> > >     Compile and run as,  for example,
> > > 
> > > ./ripoff b b t
> > > 
> > >     ("rip off two lines at the bottom,  then one at the top"),  resize
> > > horizontally,  and you'll see what I mean.  In particular,  if you shrink
> > > the window horizontally and re-expand,  you lose the text in the columns 
> > > you
> > > shrank over.
> > 
> > I don't see any text lost (in xterm, of course).  It is repainted.
> 
>    Hmmm... that's quite puzzling.  If I start in (say) an 80x25 column xterm, 
>  the ripped-off lines are shown properly.  If I expand to (say) 84 columns,  
> each line has four blanks at the end,  as could somewhat be expected.
> 
>    If I then shrink to (say) 77 columns and then return to 80,  the last 
> three columns are wiped out.

I'm using the E/e options in the ncurses test-program -
there may be some logic for repainting that I'm forgetting,
but that program doesn't lose any text.

Retesting with your sample program, I get the same result - if
I shrink the screen so that there's not enough room, then the
labels are hidden until I restore the screen-width.
 
> > >     It seems to me as if the callback function should be called (at 
> > > least) in
> > > situations where COLS changes : in initscr( ) and whenever the screen is
> > > resized horizontally.  Does this make sense to you?
> > 
> > perhaps as a new function, but not really for the existing function.
> 
>    Given the need for backward compatibility,  I'd have to agree.  The best 
> we can do is to ensure that if the screen is resized to be smaller 
> horizontally,  then restored,  we don't lose columns.
> 
> Thanks!         -- Bill

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

signature.asc
Description: PGP signature