[GRASS-dev] New installation for wxPython GUI

Glynn Clements glynn at gclements.plus.com
Tue Aug 15 02:30:34 EDT 2006


Trevor Wiens wrote:

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

Apart from possibly eliminating the need to type the "d.", I don't
really see much point in writing wrappers for all of the d.* commands.

The GUI commands will inevitably mirror the d.* commands to some
extent, as those are the only mechanism through which the GUI can
display anything.

Any feature provided by the GUI will need to be based upon a d.*
command, and any d.* command should be available through the GUI.

And, unless you manage to abstract the d.* layer away perfectly (which
is likely to be harder than it seems), users will need to learn two
sets of commands.

IMHO, it would make more sense (and reduce code bloat) if a GUI layer
was simply an arbitrary d.* command. At least, any other approach
would appear to require justification as to its benefits.

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

Regardless as to the merits of a GUI, the need to be able to perform
all tasks (including viewing maps) from a shell remains. In order to
be able to remove the existing monitors, it is necessary to have a
suitable replacement, which means the ability to use the GUI as
nothing more than a monitor.

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

bash sucks as a programming language. It's a perfectly good
interactive shell, and will remain the primary interface to GRASS for
a signficant proportion of its user base.

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




More information about the grass-dev mailing list