[GRASS-dev] New installation for wxPython GUI

[Trevor Wiens]

On Tue, 15 Aug 2006 04:03:17 +0100
Glynn Clements <glynn at gclements.plus.com> wrote:


Glynn, 

Perhaps I'm not being clear, thus there are some lengthy comments below
to try to rectify that.

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

compare "m.layer add rast foo" with "m.layer add d.rast foo". To a new
user would be unintuitive to add a command inside a command and in my
opinion, OO bad design. This complicates the interaction and serves no
functional purpose. A set of simple to use commands if properly thought
out would not require any change in end use if d.* commands changed or
were eventually removed. Only the development team would need to make
changes to the CLI GUI control commands.

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

I'm not suggesting that d.* should be removed at this time, but let's
face it, individual d.rast, d.vect, etc use is a pretty clunky way of
drawing a map. Adding layers and issuing a draw or zoom, etc. command
is much more elegant and intuitive. I don't see what functionality is
lost in doing so. Further, as d.* commands don't lend themselves, IMO,
to building a proper cartographic interface which needs to have as the
root, a page (which could be either a screen display or a printed page
size) containing frames which in turn could contain maps, text or
external graphics. I realize that GRASS is an analysis oriented system
but there is no reason (other than manpower limitations) why it
couldn't have a decent cartographic interface that was just part of the
ordinary use of the system so after viewing, printing would be
straightforward and would require no extra tweaking in most cases. As
you pointed out earlier, there are always cases which require special
tweaking, but I reiterate that this should be the exception not the
rule. 

My personal interest and involvement is to make GRASS more elegant to
use. In my opinion GRASS is not lacking in power, but the learning
curve is steep and it is not elegant to use.  Specifically having a
decent scripting environment (eventually dumping bash dependency
because as you've pointed out on numerous occasions bash sucks but
designing the new gui/cli interface so that users who like bash can
continue to use it for the foreseeable future); integrating the GUI and
the shell so that the transition from newbie to poweruser is quicker
and more natural (in this case allowing full GUI control from CLI and
building the new GUI to help users learn simple scripting through
ordinary use); and third to improve cartographic control so that one
can generate publication quality output without a lot easily. Which in
my mind would be providing at least as good output as GMT (which IMO
sucks, but is the best free game in town right now). 

In my mind to meet these goals, a better set of CLI commands are needed
that use the current back end commands (d.*), but would eventually
replace the use of the d.* commands not because the old commands didn't
work any more, but because the new interface would be more elegant and
quicker to use.

Perhaps that is clearer both where I'm coming from and what I want to
do.

T
-- 
Trevor Wiens 
twiens at interbaun.com

The significant problems that we face cannot be solved at the same 
level of thinking we were at when we created them. 
(Albert Einstein)