bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ripoffline() behavior with resizable windows


From: Thomas Dickey
Subject: Re: ripoffline() behavior with resizable windows
Date: Thu, 5 Oct 2023 04:10:55 -0400

On Wed, Oct 04, 2023 at 08:10:52PM -0400, Bill Gray wrote:
> On 10/3/23 19:46, Thomas Dickey wrote:>>     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.
>    Ah,  sorry,  I wasn't as clear as I should have been.  I don't see any
> issues with the SLK lines (in either ncurses or PDCursesMod).  The problems
> only occur with "other",  non-SLK ripped-off lines.  If you run my test code
> as,  say,

In that case, it seems consistent with the treatment of windows: ncurses
doesn't know the application's preference for the window layout, so it
clears the area to make it predictable.
 
> ./ripoff s1 b t b
> 
>    and then do the resizing,  the SLK labels do indeed redraw properly.  But
> the other two ripped-off lines at the bottom and the one at the top don't :
> when the screen shrinks horizontally,  the 'lost' columns stay that way when
> it's expanded.
> 
>    Incidentally,  another (slightly) odd bit : if you rearrange the
> command-line arguments to read
> 
> ./ripoff b s1 b t
> 
>    then the SLK labels appear in between the two ripped-from-the-bottom
> lines :
> 
> https://projectpluto.com/temp/z.png
> 
>    Which actually makes sense to me,  since the SLK labels are just re-using
> the ripped-off-line functionality.
> 
> -- Bill

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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]