[Top][All Lists]

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

Re: move_panel and getbegxy

From: Thomas Dickey
Subject: Re: move_panel and getbegxy
Date: Fri, 25 May 2007 11:02:23 -0400 (EDT)

On Fri, 25 May 2007, Bryan Christ wrote:

I'm not really a fan of the keeping the bug for compatibility, but I understand it. Your solution below considers only ncurses. The problem is that if the bug exists in pcurses and curses, then you have portability problems. In other words, its best if curses, pcurses, and ncurses all behave the same (even in the ways they are broke).

right - there are several implementations of curses (the SVr4-derived,
PDCurses, NetBSD curses and ncurses), all of which could use forms
and menus.  While there are occasional errors, ncurses "should" behave
the same as the SVr4 forms/menus libraries to make it simple for people to move code to/from each.

Extensions can be a nice thing, but (the exceptions in ncurses aren't my work, iirc), extensions should be for things that can't be done except by modifying the library - and should be optional features that can be easily omitted.

For instance, I'd be most interested in adding move_menu() as an extension if I investigated SVR4 curses and found that there was no way to move a menu with it - not even with code as in my test-driver. Then there's no existing functionality to be incompatible with. If I found that mvwin() somehow (by magic?) did the right thing for moving a menu, then there'd be a bug to address in ncurses. Otherwise, if the same move_menu() worked for SVr4 curses, it would be nice for an add-on library, but not useful for anyone who's porting code...

Clive Nicolson wrote:
On Thu, 24 May 2007, Bryan Christ wrote:

This is a bug which Thomas and I discussed sometime ago. You'll basically have to move the subwin yourself. A sample is below.

Thomas may have the other half of this email, I can't seem to find the follow up, but at least this will clear things up for you a bit. Basically, even though its a bug, other implementations of curses have this problem and so to fix it would break compatibility.

Your code snippet below fixed both my problems.

I do not support the compatibility idea, once getbegxy returns the wrong value the caller can not fix the values. Without private curses data it is not possible, even then a general fix by the caller is very difficult.

If there is some case I've missed ncurses could offer the user a runtime
switch to fix the problem.



I'm prepared to try knocking up a patch to ncurses for this bug.


On Wed, 31 May 2006, Christ, Bryan wrote:


menu_driver() reads window->_begx and window->_begy when determining the
appropriate region/coordinates to update.  The problem with this is that
_begx and _begy don't get updated if the window is a subwin/derwin and
the parent is moved.  the outdated coords cause the mouse hit-test
processed by menu_driver() to fail.  why can't this bug be fixed so that
menu_driver calculates the offset?  currently i am hacking changes to my
subwins (and subwins of subwins of subwins...) to reflect the new data.
code snippet below:




Clive Nicolson wrote:
I am using ncurses-5.6 .

I have a panel who's window is associated with a menu (for which I provided
a subwindow via derwin).

I move the panel with move_panel and then do a getbegxy on both the window and the menu's subwindow, the coordinate pairs returned indicate that the subwindow has not moved, but that the window has!

Is this expected?

I also note that the menu_driver can no longer select items (with the mouse)
on the moved menu!


Bug-ncurses mailing list

Bug-ncurses mailing list

Thomas E. Dickey

reply via email to

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