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

[Glynn Clements]

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

Either the panel stuff can be removed from the drivers, or it can't. 
If it's removed, anything which tries to use it will fail.

> > 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_() ?

Interaction belongs in the GUI, not in modules.

The panel stuff has fewer users than R_get_location_*, so getting to
the point where it can be removed is less work.

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

In which case, the functionality needs to be added to the Tcl version.

> Again, yes tag it
> as end-of-line; but don't remove it during 6.x.

Is there an expected timeline for 7.x? If so, does that signify a
point at which fundamental changes to the graphics architecture can
commence?

If not, i.e. if i.ortho.photo *has* to continue to work until such
time that someone sees fit to write an alternative (if that ever
happens), then the graphics architecture will forever be limited to a
Tek4105 emulation, and I may as well give up now.

IMHO, I don't think that we can wait forever for decent graphics. The
biggest danger is that the "you can't remove that because someone
still uses it" problem will end up solving itself when no-one actually
uses GRASS any more. I'd prefer people to set achievable goals than to
insist on having everything and ending up with nothing.

> > TCL d.rast.edit
> 
> I look forward to trying it out. Overlay numbers are needed;

The category number for the cell under the pointer is displayed in the
status bar, but if the category numbers *need* to be overlayed (bear
in mind that these may be several digits long, which means that you
need very large cells), I can add that.

> arrows aren't critical;

It isn't whether they're critical. If they're even *useful*, I can add
them easily enough (although it would be preferable if the aspect map
was given as a command-line option, otherwise I need to add a map
browser).

> updated colors would be nice.

Right now, there doesn't appear to be any simple way to determine the
colour for a specific category from outside of C.

The Tcl/Tk d.rast.edit gets the categories for the map being edited
from r.out.ascii, and the colours from r.out.ppm. Thus, it knows the
colour for each category (or FP value) which actually occurs in the
original map.

If you decide to set a cell to a category which wasn't already in use,
it has no idea what colour it should be, and (AFAICT) no simpler way
to find out than:

	$ r.mapcalc "$tempmap = $newval"
	$ r.colors $tempmap rast=$inmap
	$ r.out.ppm $tempmap out=$tempfile
	$ g.remove rast=$tempmap

	% image create photo tempimg -file $tempfile
	% set rgb [tempimg get 0 0]
	% image delete tempimg
	% file delete $tempfile

Which is incredibly inefficient (and possibly error-prone).

Right now, if it doesn't know the correct colour, it uses white. The
edited map has its colour table copied from the original map, so they
will show up correctly in the final map, just not in the editor.

-- 
Glynn Clements <glynn at gclements.plus.com>