[GRASS-dev] d.menu, d.ask

[Hamish]

Glynn Clements wrote:
> Can d.menu, d.ask, and i.ask be removed? Nothing appears to use them
> (except each other; d.ask uses d.menu and i.ask).

While I agree that they* should be removed in time, they shouldn't be
removed during the 6.x line. Nothing in GRASS may use them (except each
other), but that is not to say that there isn't some user app out there
using them. While I don't need d.menu in my work, I've always found it
to be very interesting to play with.

[*] + i.[v]points + xterm based libedit stuff


Two ways out without grinding useful development to a halt-

a) Is there a way to isolate the needed code in lib_ancient or somewhere
and conditionalize that so it+modules doesn't get built if 
./config --without-x?

b) We start on GRASS 7.x. IMO we should decide on if we want to use a
wxPython GUI or Tcl GUI for GRASS 6.4 before we decide to start that,
and do the raster format dir rearangement as the first task. I presume
the low-level raster format change can happen later, just use different
element names for the new format ($MAPSET/raster/$MAPNAME/element).


> Apart from being an artifact of using libraster as a GUI toolkit,
> D_popup() is one of the few users of the R_panel_*() functions. The
> only other users are non-essential functionality in d.barscale

I'm a big fan of the 'd.barscale -m' try-before-you-buy functionality;
In fact I've always meant to port that to d.text.* and d.legend, but so
far haven't found the time. It would be slower, but some form of 100%
panel swap or overlay might work as a way to keep the functionality
while removing R_panel_() ?

> and d.what.vect, i.ask (again), i.[v]points (which should be
> superseded by the gis.m georectifier) and i.ortho.photo (which has
> replaced v.digit as the primary obstacle to a decent graphics
> architecture).

i.[v]points remains my prefered georectifying tool, and there is still
functionality that is not present in the Tcl version. Again, yes tag it
as end-of-line; but don't remove it during 6.x.


> TCL d.rast.edit

I look forward to trying it out. Overlay numbers are needed; arrows
aren't critical; updated colors would be nice.


thanks,
Hamish