Created on 2004-07-04 11:33 by doko, last changed 2014-04-15 15:47 by akuchling. This issue is now closed.
|msg21400 - (view)||Author: Matthias Klose (doko) *||Date: 2004-07-04 11:33|
[forwarded from http://bugs.debian.org/257472] When derived windows of stdscr have been created, shrinking the terminal produces a KEY_RESIZE event, but getmaxyx() returns the previous terminal size. Only by increasing the window size does it return the correct terminal dimensions. A minimal script to show this effect is included below. #!/usr/bin/python import curses, sys def init_display(stdscr): stdscr.clear() stdscr.refresh() size = stdscr.getmaxyx() sys.stderr.write("Now %u x %u\n" % (size,size)) rootwin = stdscr.derwin(20, 50, 0, 0) return rootwin def main(stdscr): rootwin = init_display(stdscr) while 1: input = rootwin.getch() if ( input == curses.KEY_RESIZE): init_display(stdscr) elif input == ord("q"): sys.exit() rootwin.refresh() curses.wrapper(main)
|msg21401 - (view)||Author: A.M. Kuchling (akuchling) *||Date: 2004-07-07 13:19|
Logged In: YES user_id=11375 Confirmed. I suspect this is a problem in ncurses, and will write a C equivalent of the test program to verify this. The ncurses man page for derwin says: "The subwindow functions (subwin, derwin, ...) are flaky, incompletely implemented, and not well tested," so an ncurses bug seems likely.
|msg82043 - (view)||Author: Daniel Diniz (ajaksu2)||Date: 2009-02-14 12:58|
I get a different behavior, with shrinking reporting correct sizes, but quiting with a "_curses.error: curses function returned NULL", on trunk, KDE 3.5's Konsole._curses.error: curses function returned NULL
|msg133937 - (view)||Author: Akira Li (akira) *||Date: 2011-04-17 19:58|
The test produces a traceback while shrinking a window (increasing the window size works ok): Traceback (most recent call last): File "screen-resize-bug-curses.py", line 22, in <module> curses.wrapper(main) File "/.../python2.7/curses/wrapper.py", line 43, in wrapper return func(stdscr, *args, **kwds) File "screen-resize-bug-curses.py", line 17, in main init_display(stdscr) File "screen-resize-bug-curses.py", line 9, in init_display rootwin = stdscr.derwin(20, 50, 0, 0) _curses.error: curses function returned NULL Version info: $ python2.7 -c'import curses; print curses.version' 2.2
|msg216205 - (view)||Author: Christian Hudon (chrish42) *||Date: 2014-04-14 20:39|
I get the same traceback. The traceback happens only when the window is shrunk below the size specified in derwin(). It's easy to see this by changing the first and second arguments to the derwin call to something like 2, 2, and then you can resize the window to a much smaller size without getting this exception. (My curses.version is 2.2 also. Running on OSX Mavericks.) The getmaxyx() function reports the correct size when the window is shrunk. Also note that the upstream bug has been closed, with the comment "Not seen in python 2.7". So I think we can close this. Maybe we want to document the behavior of derwin() and related functions of raising _curses.error when the dimensions of the terminal are smaller than that of the window, though? (Or maybe raise a better exception?) That should probably be another bug report, though.
|msg216319 - (view)||Author: A.M. Kuchling (akuchling) *||Date: 2014-04-15 15:47|
I agree with Chris's logic; the incorrect size seems to be a curses/ncurses bug that has gotten fixed somewhere along the line. You also aren't able to shrink the terminal to be smaller than the size of a derived window created with derwin(), but you seem to get an exception when you try rather than a crash. This seems reasonable to me. I don't think we need to document this behaviour, because that edge case would really belong in the ncurses documentation (and they might change it from version to version).
|2014-04-15 15:47:58||akuchling||set||status: open -> closed|
resolution: not a bug
messages: + msg216319
stage: test needed -> resolved
messages: + msg216205
messages: + msg133937
|2010-08-19 15:05:13||BreamoreBoy||set||versions: + Python 3.1, Python 2.7, Python 3.2, - Python 2.6|
stage: test needed
messages: + msg82043
versions: + Python 2.6, - Python 2.3