[GRASS5] Darwin Pre1 gtty stty errors

[Glynn Clements]

Eric G. Miller wrote:

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

OK; so it's already there. In which case, ignore the comments about
using Vask. It seems that the way to go would be to scrap the Q&A and
extend front.end.

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

Do you have any specific cases? That sort of thing should probably be
fixed for 5.0.0.

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

Unfortunately it's not that simple.

Right now, a lot of code assumes that it is part of a stand-alone
program, e.g. calling exit() on errors, not keeping track of
dynamically-allocated memory (as it's going to be cleaned up on exit)
and so on.

Personally I don't see any problem with the commands being distinct
programs run as separate processes. The insulation provided by the
Unix process mechanism has its advantages.

As long as the individual commands are implemented with modularity in
mind, it should still be possible to build a decent GUI framework on
top of them. The end result may also have some advantages over a
monolithic application.

The real obstacle is programs which try to be applications in
themselves, e.g. implementing half-baked user-interaction using curses
or (worse still) XDRIVER (e.g. "d.display"). I'm guessing that at
least some of this goes back to pre-X days (I've noticed the reference
to "Tektronix 4105" lurking in the default etc/monitorcap).

> But then the spec. for the "module" would need to be handled
> differently (individual "spec" files?).

I didn't get this bit.

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

That doesn't really relate to the issue of assigning colours to raster
maps. A raster cell stores either a discrete category or scalar value,
not a colour. Regardless of display hardware, colour tables
("palettes") are still an essential part of the process, so a means to
edit them is still necessary.

It seems more likely that d.colors would simply be replaced with a GUI
version. It doesn't seem likely that anyone would want to
interactively edit colour tables without being able to see the results
(which implies running XDRIVER, which implies being able to run a GUI
tool).

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