[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