On Thu, 7 Jun 2007, Thomas Dickey wrote:
On Thu, 7 Jun 2007, Clive Nicolson wrote:
Oops I forgot to attach the code.
Hi,
here is some code which demonstrates how to fix the "menu subwin moving"
problem for mvwin. This code is nonrecursive and I think will not
break user code which traverses the window parent tree and
recalculates _begy
and _begx. It also fixes the "form subwin moving" problem!
mvderwin needs a somewhat slightly different fix.
Anyone want a patch?
not exactly. Let's go back to the top of the discussion. What's
needed is a concise proposal for
(a) an identifiable mismatch between ncurses behavior that leads to a
fix or
The problem is that [n]curses documents getbegyx thus:
"Like getyx, the getbegyx and getmaxyx macros store the current
beginning coordinates and size of the specified window."
There is no statement about getbegyx returning the wrong values for a
subwindow
if its parent window has been moved by mvwin, or have I missed it?
(b) an example of how to provide the functionality without modifying
ncurses or
Others have done this, but it requires reaching into structures that should
be opaque.
(c) a new feature which could be used to provide the functionality,
e.g., an extension
One could treat the fix as an extension by #define NCURSES_MVWIN_FIXED
or some such mechanism.
I do not think my proposed fix will break any existing code, other than
that
which uses values from getbegyx to somehow move a window and its subwindows
back to their positions before the parent window had been moved with mvwin.
My proposed fix provides the least surprise (in the values returned by
getbegyx on a sub window) after a mvwin on its parent window.
As for compatibility with other implementations of curses, let us assume
that ncurses is the leading implementation and that the others will follow
with a similar fix.
The only other fix would be to correct the documentation for getbegyx and
mvwin.
Clive
...