[GRASS-dev] New installation for wxPython GUI

Glynn Clements glynn at gclements.plus.com
Mon Aug 14 23:03:17 EDT 2006


twiens wrote:

> > > In this context however the issuing of
> > > d.* commands would pretty much disappear from CLI use.
> > > Instead users would do something like "g.ui map1 add
> > > rast foo", "g.ui map1 redraw", or "g.ui map1 tree" (to
> > > see the display tree in a simple text representation).
> > 
> > In the "add" case, you may as well just specify the name
> > of the actual command which will be used to perform the
> > rendering (e.g. "d.rast") rather than creating a new
> > GUI-specific layer. IOW, every layer would be a "command"
> > layer.
> 
> I disagree. If we are thinking of rewriting some of these commands 
> it makes more sense to me to remove them from use with as simple a 
> command line interface as possible that will not need to be changed 
> in the future.

Backward compatibility dictates that the core d.* commands have to
continue to work from the command line for a while yet.

Also, as these commands need to remain in order for the GUI to work,
they may as well continue to work as standalone commands.

> Thus whatever changes behind the scenes are implemented 
> by developers and as little as possible of the user developed scripts break. 

That's the main point of ensuring that d.* continue to work as
standalone commands.

> Further, by making every layer a command layer, just means more redundant
> typing and making GRASS CLI use more difficult for newbies.

Why?

> I don't want to 
> see GRASS dumbed down, but if I can make it easier to use with no loss of 
> control or functionality, why not?

Making d.* stop working is loss of functionality.

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




More information about the grass-dev mailing list