Mailing List Archive

decisions, decisions (module support)
[. This is perhaps only peripherally connected to the perl5-porters
charter, but I feel it can be instructive to others. If you feel
otherwise, feel free not to CC: back to the list. ]

I am in the beginning stages of a possible problem with the Curses
module I maintain. Likely, in a few weeks, the ncurses development
team will finally release ncurses v2.0. This version of the curses
API will have just about everything: major compliance to the XPG4
Curses standard (XSI curses), support for all the 257 System V Curses
calls, better scrolling and hardware support, SysV panels and menus
library emulation, mouse support (!), and a host of other neato
features.

In addition, ncurses v2 will have GNU configure support, making it
(potentially) compilable on most platforms. Keith Bostic has
officially declared BSD curses dead, and ncurses the successor.
Basically, once ncurses v2 comes out, there will be very little reason
to use *any* other curses out there.

Right now, we're stuck with a dozen different incompatible dialects of
the curses API. There are perhaps only a dozen functions that exist
across all the versions, making Curses scripts a *major* pain to write
for portability, and even among those functions, there are sometimes
quirks.

So the problem becomes, what do I support? If I were to declare
support solely for ncurses v2, I'd probably be alienating those with
weird systems (sorry Andy :-), at least until the ncurses development
team provides support. There would also be a fairly extensive
"prep time", requiring the install of ncurses v2 and possibly the
accompanying terminfo database.

On the other hand, my life would be immensely simplified (always a
good selling point :-) and people would be able to write non-trivial
Curses scripts that would run on any machine supported by Curses.
I'm mostly convinced that "forcing" people not to use their system's
curses is a Good Thing. But I don't particularly want to support
two versions of the Curses module, for all the obvious reasons.

So, finally I get to the reason for this long, boring missive: What do
you think would be the Right Thing to do? Try to continue support the
old, painful curses, or force people to use ncurses for their own
good? The Curses module is still in alpha, so I have an excuse to
change everything if I want (ah, the benefits of never going into beta
:-), but I would like my module to be useful to as many as possible.
I feel I'm too close to this issue to form an objective opinion, so
I'd really like to hear others.


William
Re: decisions, decisions (module support) [ In reply to ]
On Mon, 9 Oct 1995, William Setzer wrote:

> [...]
> On the other hand, my life would be immensely simplified (always a
> good selling point :-) and people would be able to write non-trivial
> Curses scripts that would run on any machine supported by Curses.
> I'm mostly convinced that "forcing" people not to use their system's
> curses is a Good Thing. But I don't particularly want to support
> two versions of the Curses module, for all the obvious reasons.

I've been playing around with Term::Control (A module that can use Curses,
termcap, terminfo, BIOS, VIO, or whatever) for some time, so I definitely
have some thoughts on this subject.

The key question, I think, is whether ncurses v2 is a proper superset of
all other curses, and all other curses are proper subsets of ncurses v2.
If this was true, then all you'd have to do is figure out what
functionality is available in the local curses, via a Configure style
probing, and adapt the module to the results.

This of course is almost definitely not the case, and even if it was,
there is another question: for the missing functionality, should you just
leave it missing, or attempt to emulate it?

> So, finally I get to the reason for this long, boring missive: What do
> you think would be the Right Thing to do? Try to continue support the
> old, painful curses, or force people to use ncurses for their own
> good? The Curses module is still in alpha, so I have an excuse to
> change everything if I want (ah, the benefits of never going into beta
> :-), but I would like my module to be useful to as many as possible.
> I feel I'm too close to this issue to form an objective opinion, so
> I'd really like to hear others.

I'd strongly suggest the break-away style as I described above. If you
need help with scanning the local curses library, you might like to look
at Configure.pm in Term::ReadKey.

If you don't think you can do this... well, there really isn't an option
is there? Just support ncurses, and forget about the broken curses of the
world. Ncurses will eventually be ported everywhere, so only supporting it
isn't that bad a move.

> William

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
Re: decisions, decisions (module support) [ In reply to ]
Excerpts from the mail message of William Setzer:
) So the problem becomes, what do I support? If I were to declare
) support solely for ncurses v2, I'd probably be alienating those with
) weird systems (sorry Andy :-), at least until the ncurses development
) team provides support. There would also be a fairly extensive
) "prep time", requiring the install of ncurses v2 and possibly the
) accompanying terminfo database.

Perhaps you could freeze what you currently have that supports
multiple curses and then use it to start a new module that
provides much more functionality but only supports ncurses v2?
--
Tye McQueen tye@metronet.com || tye@doober.usu.edu
Nothing is obvious unless you are overlooking something
http://www.metronet.com/~tye/ (scripts, links, nothing fancy)
Re: decisions, decisions (module support) [ In reply to ]
> From: Tye McQueen <tye@metronet.com>
>
> Excerpts from the mail message of William Setzer:
> ) So the problem becomes, what do I support? If I were to declare
> ) support solely for ncurses v2, I'd probably be alienating those with
> ) weird systems (sorry Andy :-), at least until the ncurses development
> ) team provides support. There would also be a fairly extensive
> ) "prep time", requiring the install of ncurses v2 and possibly the
> ) accompanying terminfo database.
>
> Perhaps you could freeze what you currently have that supports
> multiple curses and then use it to start a new module that
> provides much more functionality but only supports ncurses v2?

That would be my approach.

Tim.
Re: decisions, decisions (module support) [ In reply to ]
William Setzer <setzer@guest3.math.ncsu.edu> writes:
>
> So, finally I get to the reason for this long, boring missive: What do
> you think would be the Right Thing to do? Try to continue support the
> old, painful curses, or force people to use ncurses for their own
> good? The Curses module is still in alpha, so I have an excuse to
> change everything if I want (ah, the benefits of never going into beta
> :-), but I would like my module to be useful to as many as possible.
> I feel I'm too close to this issue to form an objective opinion, so
> I'd really like to hear others.
>
>
Personally, I think I would abandon the current curses module to the
public domain and start providing a new curses module, effectively
NCurses.pm ... pardon the pun, which only supports the use of ncurses.

Mike
mhm@austin.ibm.com
Re: decisions, decisions (module support) [ In reply to ]
My thanks to all of those who responded to my query on curses support.
It seems unanimous that I should freeze the current module after the
next release and go with a 'NCurses' module thereafter. That sounds
like a winner to me.


William

PS: If ncurses v2 does all it's supposed to do, it might actually be
possible and not-so-painful to emulate portions of the Tk module.
That alone might be a good enough reason to support ncurses. :-)