[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sat, 8 Aug 2020 15:52:09 -0400
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
I've been working for some years on a fork of PDCurses. As a
result, I often refer to ncurses to get a sense of what the
behavior "ought" to be. (When there's a bug or poor behavior,
it's almost always on the PDCurses side. I don't think I've
encountered a reportable ncurses issue. This is my first post
to this list, and it's still not because ncurses is wrong.)
Recently, I investigated some issues in the PDCurses panels
library. I wrote a small demo to put three panels on-screen :
Run this in a terminal, grab the lower right corner of the terminal
and shrink it so that the windows stick off-screen, and it all works
if the program is compiled with ncurses. To my knowledge, this is
the only way in ncurses or PDCurses to get a window to be partly or
completely off-screen. You can't call mvwin() to do it, but if a
user resizes the terminal, ncurses handles the off-screen panel
correctly. (Are there other ways to get partially or fully off-screen
windows/panels in ncurses?)
My fork of PDCurses crashed when required to handle off-screen
panels/windows, but that was easy to fix.
I then tried commenting out lines 294-296 at
...i.e., "go ahead and allow mvwin() to put windows off-screen."
Thus far, I've seen no problems with this; I can move panels
partly or completely off-screen, much as one can with windows in
a traditional GUI. Which seems as if it could be useful.
Is there a reason ncurses requires windows/panels to be on-screen
(with the exception of resized terminals)? Out of caution, I'm
inclined to add to my fork of PDCurses a function such as...
void allow_offscreen_windows( const bool);
...defaulting to not allowing them except in the case of the
screen being resized to chop them off. But at least thus far,
I've seen no downside to allowing offscreen windows/panels.
- Off-screen panels/windows,
Bill Gray <=