CURSES - sub-windows bugs and features...

[idallen at watmath.UUCP]

These apply to Curses as distributed with 4.2bsd and dated June/July 1983.
They probably also apply to 4.1bsd curses.

>> ONE ------------------------------------------

    If you add text to a sub-window, and refresh the parent window,
    the text in the sub-window is shown correctly.  But, if you then
    clear or erase or insert/delete a character in the sub-window, or
    clear to end of line, or clear to the bottom of the sub-window, 
    and refresh the parent window, nothing happens.  In fact, the only
    change you can make to a sub-window that will be noticed by the
    parent window is to add a character or string.

Is this a bug or a feature?

Analysis:
    When you add a character to a window, the line-by-line change
    flags are updated for all related (by parent or child) windows.
    So, when you refresh any of the related windows, the right thing
    happens.  But when a window is erased, or a line cleared, the
    normal add-character function is bypassed in favour of stomping
    down blanks in a hurry.  Only the change flags for the particular
    window being erased are updated.  Related windows are not told, and
    refreshing them has no effect.  I think this is a bug, not a
    feature.  If you can add text to a sub-window and make it visible
    by refreshing the parent, then you should be able to delete it
    using the same refresh method.  Comments?

>> TWO ------------------------------------------

    Sub-windows don't get told about line movement in their parent
    windows, nor vice versa.  If you insert or delete a line in, or
    scroll, the parent window, the sub-window shows the right lines,
    but in the wrong order.  The same problem is evident in parent
    windows for actions on their sub-windows.  The result is two
    different screen views, when the parent and sub windows are
    alternately touched and refreshed.

This has to be a bug.

Analysis:
    A sub-window is just an edge vector of pointers to positions in the
    parent window's lines.  When the parent shifts the pointers in its
    own edge vector to move or deleta a line, it doesn't tell the
    sub-window.  The sub-window's pointers still point to the same lines
    in the old order.  Refreshing the sub-window puts out the lines in
    the old order.  This has the curious effect of making a blank line
    appear in the middle of the screen when the parent deletes the
    corresponding line, and making the bottom line go blank when the
    parent inserts a line.  Scrolling a parent window has no effect on
    the sub-window, since the sub-window still has the lines in the old
    order.  This can produce delightful (?) effects when the parent
    window and sub-window are alternately touched and refreshed. 
    Conversely, if you scroll a sub-window, or insert or delete lines
    therein, the parent window doesn't get told, and the refreshing of
    the parent and sub windows gives two different views.
------------------------------------------------------------------------------
It looks to me like sub-windows were added to CURSES at the last
minute, and someone forgot to integrate them with all the possible
operations possible on windows.  One slow and expensive fix to the above
would be to make the blank-writing that erases a window use addch().
This won't help the delch() and insch() functions, mind you.
Another (better?) fix would be to make all the routines that set the line
change flags do it for all related windows too, like addch() does.
-- 
        -IAN!  (Ian! D. Allen)      University of Waterloo