[GRASS-dev] d.rast.edit in wxgrass

[Glynn Clements]

Michael Barton wrote:

> >> If the command HAS arguments and IS a d.* command, it is added to the list
> >> of display layers managed within render.py for the map display that has the
> >> focus and the UpdateMap method is called to update that display. There is a
> >> 2nd splitting that allows for multiple d.* commands to be separated by
> >> semi-colons. This may or may not be a good idea in the end, but I thought
> >> I'd see how it worked out.
> > 
> > This all looks suspiciously like DWIM, which is normally a bad thing
> > for non-trivial systems.
> > 
> 
> I don't think it is a DWIM. The normal CLI behavior currently is...
> 
> 1) type a command without arguments and it (normally) opens a properties
> dialog;
> 
> 2) type a command with arguments and it runs the command. To run a d.*
> command and have it do anything useful in the wxgrass environment, it needs
> to be added to the list of display layers and the display updated.

Not all d.* commands generate graphics. Admittedly, most of the ones
which don't are only useful with a standalone monitor. I don't know
whether there are any other exceptions apart from d.rast.edit
(technically, the original v.digit should have had a d.* prefix, e.g. 
d.vect.edit, but it doesn't).

For the d.* hack to work, we will need to adopt (and enforce) a rule
that the d.* prefix is reserved solely for commands which generate
graphics. That will become more practical in 7.x, as the display
"management" commands (d.mon, d.save, d.info etc) will no longer be
relevant once standalone monitors cease to exist.

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