[GRASS5] Darwin Pre1 gtty stty errors

[Glynn Clements]

Eric G. Miller wrote:

> > I haven't looked into merging the various versions of curses.c yet. 
> > For that, I would be interested in comments as to whether the code
> > belongs in any of the existing libraries, or if there should be a new
> > library for curses support routines.
> 
> Glynn, if my guess at the history is correct, maybe these curses files
> predate the Vask library?  Vask is supposed to be a wrapper for the
> variants of curses libraries.  So presumably if there's some missing
> functionality, it should be ported to the Vask library.  Personally, I'm
> not sure I like the Vask library too much, seems we could track down a
> nicer text/console library.

AFAICT, Vask is specifically for inputting data using "forms", rather
than generic curses I/O. It's probably best if it stays this way.

I can see a potential advantage in the Vask interface, namely that it
would be possible to implement a compatible alternative which used GUI
dialogs. An application could then use whichever version was
appropriate, e.g. based upon the GRASS_GUI setting.

It would be nice to updating the API to use more specific types than
just string, integer, long, float and double, though. Similarly for
G_parser(). A further improvement would be to pass "context"
information to enable transparent support for features such as history
lists.

Also, it might be a good idea for G_parser() to use Vask instead of a
teletype-style Q&A session. Either that, or have the program output a
machine-readable argument summary which could be parsed by a generic
front-end or tcltkgrass (which would eliminate the need for all of the
src/tcltkgrass/module/* files).

However, this doesn't answer the question of what to do with programs
for which Vask isn't suitable (e.g. d.colors). The more individual
programs implement their own UI, the harder it is to get consistency
throughout GRASS.

Personally, I'm a firm supporter of separating content from form. In
the context of GRASS, this equates to separating functionality from
interface. Particularly when you have a lot of useful functionality
but the interface often sucks.

BTW, this doesn't really apply to d.colors, which is almost entirely
interface.

Anyway, I'll stop there. The whole "framework" issue is a big can of
worms which is probably best left for 5.1/6.0. For now, I'm just
interested in avoiding duplication where possible.

-- 
Glynn Clements <glynn.clements at virgin.net>