Re: curses: create panel from stdscr?
In article <20171108210902.ga...@internode.on.net>, Brett Lymn wrote: >On Wed, Nov 08, 2017 at 01:04:31AM +, Christos Zoulas wrote: >> >> 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. >> > >In theory this would be a good strategy but, unfortunately, we are >talking about a library that is layered over the top of curses. There >really is no sane way of printing something to the screen that will not >either be invisible or mess up the layout of the terminal. We could add >it as a debug but even that is unlikely to be seen. We can add something that saves the contents of the screen, clears the screen prints the message, waits for a and then restores the screen. christos
Re: curses: create panel from stdscr?
On Wed, Nov 08, 2017 at 01:04:31AM +, Christos Zoulas wrote: > > 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. > In theory this would be a good strategy but, unfortunately, we are talking about a library that is layered over the top of curses. There really is no sane way of printing something to the screen that will not either be invisible or mess up the layout of the terminal. We could add it as a debug but even that is unlikely to be seen. -- Brett Lymn Let go, or be dragged - Zen proverb.
Re: curses: create panel from stdscr?
On 11/8/2017 11:18 AM, Valery Ushakov wrote: On Wed, Nov 08, 2017 at 07:47:17 +1030, Brett Lymn wrote: On Mon, Nov 06, 2017 at 07:09:06PM +0300, Valery Ushakov wrote: This does leave us in the invidious position of our correctness being interpreted as bugs because we don't do what ncurses doesit is a constant, losing, battle. [...] 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. Shouldn't we just cvs rm our curses then? No. There are cases where ncurses deviates from the standard and also from it's own man pages - so which is the source of truth here? Roy
Re: curses: create panel from stdscr?
On Wed, Nov 08, 2017 at 07:47:17 +1030, Brett Lymn wrote: > On Mon, Nov 06, 2017 at 07:09:06PM +0300, Valery Ushakov wrote: > > This does leave us in the invidious position of our correctness > being interpreted as bugs because we don't do what ncurses > doesit is a constant, losing, battle. [...] > 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. Shouldn't we just cvs rm our curses then? As I said, in this case someone without a clue wrote a trivial test for set_panel_userptr() and created a panel for that test using stdscr because it's conveniently there, saves a line to create a new window. -uwe
Re: curses: create panel from stdscr?
On Wed, Nov 08, 2017 at 01:04:31AM +, Christos Zoulas wrote: > 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. If the standard makes sense and we follow it duefully, I don't think we should add bug compatibility. Instead we should document the differences explicitly and point to the standard. Just like this one has already been fixed upstream, future instances should be similar trivial. Martin
Re: curses: create panel from stdscr?
In article <20171107211717.gb...@internode.on.net>, Brett Lymn 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 doesit 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
Re: curses: create panel from stdscr?
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 doesit 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. -- Brett Lymn Let go, or be dragged - Zen proverb.
Re: curses: create panel from stdscr?
On Mon, Nov 06, 2017 at 12:19:51 +0100, Thomas Klausner wrote: > "The NetBSD curses library in NetBSD 8 provides the panel extension. > compatible with ncurses. 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 seems to be a difference in libpanel compared to ncurses: A > panel cannot be created from stdscr. 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. To quote the SCO's "User Interfaces Guide" from 1991: | Panels have depth only in relation to other panels and stdscr, which | lies beneath all panels. [...] | Recall that panels are always above stdscr, the standard screen. | When a panel is moved or deleted, stdscr is updated along with the | visible panels to ensure that it appears beneath all panels. | Although stdscr has depth relative to other panels, it is not a | panel, because panel operations like top_panel() and bottom_panel() | do not apply. However, because stdscr rests beneath the deck of | panels, you should always call update_panels() when you work with | panels and change stdscr, even if you do not change any panels. A panel object for stdscr actually does (almost) always exists internally in my implementation but it's never exposed to the user. > This causes failing two tests in test_curses. These tests were added > not long time ago, and there are not reasons to create panels from > stdscr instead of other windows. What do these two tests test exactly? > Hence the proposed PR just makes these two tests creating panels > from new windows, as in other two tests." This sounds to me like someone wrote some some code without real understanding of what's actually going on and used stdscr simply because it already exists: yay, we can avoid creating a new window! -uwe
