[GRASS5] Darwin Pre1 gtty stty errors

[Eric G. Miller]

On Wed, Jun 06, 2001 at 06:34:07AM +0100, Glynn Clements wrote:
> 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).

See Jan's addition to the parser for and XML interface description.

GRASS ~> <cmd> --interface-description

The dtd is not copied to "etc" though it should be (or share/xml ??).
I was just playing with this the other day to parse the output from
hitting each command with the "--interface-description" flag.
Unfortunately, some modules (and shell scripts), do things before
calling G_parser() that muck this up.  An example of parsing this output
to generate an input form exists in grass/src/gui/.  I don't
particularly want to add Python and wxWindows as additional requirements
for GRASS, but it shows the possibilities.

> 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.

I don't have much experience in the interface arena, but a non-toolkit
specific wrapper that's retargetable for various platforms and i/o
capabilities would be nice.  I also would like to merge more
functionality into shared libraries and possibly even most of what
several modules do.  A callable command line program would be little
more than processing arguments through G_parser() and calling the
appropriate entry function in a shared lib.  Seems to me, this would
make it easier for GUI interfaces to implement the same functionality
without doing system(foo) -- yuck!  But then the spec. for the "module"
would need to be handled differently (individual "spec" files?).

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

Probably d.colors will disappear eventually.  24bit displays are pretty
common...

> 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.

Yea, the changes are stacking up for 5.1/6.0.  We need to get 5.0 out so
everyone can move forward.  Seems there's an unending supply of triage
work for 5.0 though ;(.

-- 
Eric G. Miller <egm2 at jps.net>