Chris Share <usenet at caesium.me.ukwr ote:
>
>
odd (thanks for the example - I don't know if this is a problem in
ncurses or in the python interface to it, but will check/see).
>
>
>
>
probably should report it as a bug (so it's not overlooked).
>
--
Thomas E. Dickey
ftp://invisible-island.net
http://web.cs.mun.ca/~rod/ncurses/ncurses.html#xterm says "The ncurses
library does not catch [the SIGWINCH aka resizing] signal, because it
cannot in general know how you want the screen re-painted". First, is
this really true? When I make my xterms smaller they clip what is
displayed--is that a function of curses or the xterm?
Second, if true, it explains /what/ is going on--stdscr, only--, but
isn't really satisfactory; it doesn't solve the original poster's bug.
#!/usr/bin/env python
"""
curses_resize.p y -run the program without hooking SIGWINCH
curses_resize.p y 1 -run the program with hooking SIGWINCH
"""
import sys, curses, signal, time
def sigwinch_handle r(n, frame):
curses.endwin()
curses.initscr( )
def main(stdscr):
"""just repeatedly redraw a long string to reveal the window boundaries"""
while 1:
stdscr.insstr(0 ,0,"abcd"*40)
time.sleep(1)
if __name__=='__ma in__':
if len(sys.argv)== 2 and sys.argv[1]=="1":
signal.signal(s ignal.SIGWINCH, sigwinch_handle r)
curses.wrapper( main)
If you run this without sigwinch then the line never gets resized, but
if you do then it works fine. What we can glean from this is that
stdscr only reads off it's size upon initialization. This behaviour
may seem a bit strange, but 1) it's legacy and 2) avoids breaking the
semantics of windows (which don't change size on their own).
The "curses.initscr ()" part is kind of unhappy though. It modifies the
stdscr variable without us explicitly assigning anything (but I can't
think of any other way to do it, beyond making stdscr a global, and
that feels worse) and will break if initscr() ever returns a new
Window structure instead of just updating and returning the old one.
Does anyone have any tips for how to structure this so that the screen
can actually be assigned to?
In conclusion, it's not a bug, it's a feature. Joy! The workaround is
to write a sigwinch_handle r that at least does `endwin(); initscr()`.
Sorry for reviving an old thread, but it doesn't seem the issue was
ever resolved (the thread doesn't go anywhere and there's no warning
about this in the docs that I noticed).
(please CC: me if anyone cares, I'm not on the list)
-Nick Guenther
I've been writing an application using curses, and have been trying to
handle resizing the terminal, if running in xterm or similar. Increasing
the window size is working perfectly, however shrinking it is not
working at all. No matter how much I shrink the window, the size
returned by getmaxyx() does not change. However as soon as I increase it
again, it works fine.
handle resizing the terminal, if running in xterm or similar. Increasing
the window size is working perfectly, however shrinking it is not
working at all. No matter how much I shrink the window, the size
returned by getmaxyx() does not change. However as soon as I increase it
again, it works fine.
I've tracked the problem down to the fact I have created a window
derived from stdscr. A small script showing the effect is at the end of
this post.
derived from stdscr. A small script showing the effect is at the end of
this post.
odd (thanks for the example - I don't know if this is a problem in
ncurses or in the python interface to it, but will check/see).
>
Can anyone suggest how to solve this problem, that doesn't involve not
making a derwin of stdscr?
making a derwin of stdscr?
I've been googling for hours, but found nothing to help.
Python version is 2.3.4 on debian testing.
probably should report it as a bug (so it's not overlooked).
>
--
Thomas E. Dickey
ftp://invisible-island.net
library does not catch [the SIGWINCH aka resizing] signal, because it
cannot in general know how you want the screen re-painted". First, is
this really true? When I make my xterms smaller they clip what is
displayed--is that a function of curses or the xterm?
Second, if true, it explains /what/ is going on--stdscr, only--, but
isn't really satisfactory; it doesn't solve the original poster's bug.
#!/usr/bin/env python
"""
curses_resize.p y -run the program without hooking SIGWINCH
curses_resize.p y 1 -run the program with hooking SIGWINCH
"""
import sys, curses, signal, time
def sigwinch_handle r(n, frame):
curses.endwin()
curses.initscr( )
def main(stdscr):
"""just repeatedly redraw a long string to reveal the window boundaries"""
while 1:
stdscr.insstr(0 ,0,"abcd"*40)
time.sleep(1)
if __name__=='__ma in__':
if len(sys.argv)== 2 and sys.argv[1]=="1":
signal.signal(s ignal.SIGWINCH, sigwinch_handle r)
curses.wrapper( main)
If you run this without sigwinch then the line never gets resized, but
if you do then it works fine. What we can glean from this is that
stdscr only reads off it's size upon initialization. This behaviour
may seem a bit strange, but 1) it's legacy and 2) avoids breaking the
semantics of windows (which don't change size on their own).
The "curses.initscr ()" part is kind of unhappy though. It modifies the
stdscr variable without us explicitly assigning anything (but I can't
think of any other way to do it, beyond making stdscr a global, and
that feels worse) and will break if initscr() ever returns a new
Window structure instead of just updating and returning the old one.
Does anyone have any tips for how to structure this so that the screen
can actually be assigned to?
In conclusion, it's not a bug, it's a feature. Joy! The workaround is
to write a sigwinch_handle r that at least does `endwin(); initscr()`.
Sorry for reviving an old thread, but it doesn't seem the issue was
ever resolved (the thread doesn't go anywhere and there's no warning
about this in the docs that I noticed).
(please CC: me if anyone cares, I'm not on the list)
-Nick Guenther
Comment