In article <20171107211717.gb...@internode.on.net>, Brett Lymn <bl...@internode.on.net> wrote: >On Mon, Nov 06, 2017 at 07:09:06PM +0300, Valery Ushakov wrote: >> >> It's intended to be compatible with Extended Terminal Interface (ETI). >> When I wrote it I looked at Solaris and SCO documentation from early >> 90s. E.g. calling top_panel() on a hidden panel behaves differently. >> ETI says it's an error, ncurses shows the panel. There may be other >> differences as well. >> > >There is actually a book that defines the ETI, I have it at home >somewhere. The bits I implemented used that book as a reference. >Unfortunately, ncurses does a lot of things that are not as per the >specification. I did try to report them upstream but there seemed to be >a lack of interest in fixing things - I guess more due to breaking >things than anything else. This does leave us in the invidious position >of our correctness being interpreted as bugs because we don't do what >ncurses does....it is a constant, losing, battle. > >> >> Panels basically just add Z-order to curses windows. What would be >> meaningful operations on a panel that corresponds to stdscr? It must >> always be visible, it must always be at the bottom, it cannot be >> moved, etc, etc. What's worse is that it will probably introduce >> consistency problems into the API. >> > >Yes, even though we are correct and it makes no real sense to allow a >panel on stdscr we probably should do it otherwise we will be forever >closing bug reports and also parts of pkgsrc will require ncurses simply >because the native curses "does not work". > >It is wrong and a pain but ncurses has the larger market share so >whatever we do different is considered a but so we may as well just suck >it up and make our libpanel have the same brokenness.
Even if we become bug compatible, we should keep a mode (via environment or program setting) that warns when we are asked to do something unspecified or different than the standard, or even behaves the way the standard mandates. christos
