> But try to link it with your curses first - and then with ncurses. My former
> post was telling about executable using ncurses.
> 
> Yes, when using your curses, it seems to work a bit better in NetBSD's
> environment. Are ncurses not quite compatible with NetBSD?

Hmm, it works with colours in an xterm (NetBSD/sparc64 3.99.10) with both
curses and ncurses for me.

> I have added raw() immediately after initscr() - but I wasn't sure, is it
> the proper way.

That will also work here.  Calling raw() will stop some other processing, so
you need to check for (e.g.) ^C yourself.

> Right. Found it too. Shouldn't it just dispose of all the subwindows,
> when "parent" is already deleted? (even without a need to delete
> sub-windows separately...)

We delete sub-windows when the parent is deleted, so yes, it should just
not bother trying to delete them.  However, it passes the curses library
a reference to an already deleted window and that causes the library to go
into an infinite loop.  I wondered about changing the way we chain
sub-windows which would have the affect of removing this bug and also
allowing nested subwindows.  Being compatible with Solaris here would also
be good.

> Found another thing: it seems, that subwindows (in NetBSD's curses) cannot
> "inherite" properties (like back-/foreground colour, for example) of the
> "parent" windows. Look at that "draw_menu" procedure - before
> wbkgd(items[1],COLOR_PAIR(4)); (which shows the position of "higlight tab"),
> 
> So, the "parent" window has been set - but "children" forgot the settings.
> Is it a bug - or feature?

Bug ;-)  It should be fixed in the -current code.  I recently checked in a
change to the way we handle background attributes and should have fixed
that too.  See:

  http://mail-index.NetBSD.org/source-changes/2006/01/15/0015.html

J

-- 
  My other computer also runs NetBSD    /        Sailing at Newbiggin
        http://www.netbsd.org/        /   http://www.newbigginsailingclub.org/