[GRASS-dev] New installation for wxPython GUI

[Michael Barton]

See comments below.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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

Keep in mind that after a "m.layer add rast foo" you need to add the
arguments that tell m.layer how to composite and display foo. For some
layers (e.g., vectors, legends) there are a lot of arguments. Do you plan to
have new versions of these too? This is a lot of work. If the CLI could
simple recognize existing GRASS commands, it would save a lot of coding.

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

A cartographic module would be welcomed by many (though my experience with
commercial products keeps me skeptical about its real utility). To me, page
layout works better if it is wrapped in a GUI (even if you can specify
individual item properties like size, fonts, kerning, etc.). That's why most
of the world uses programs like PageMaker instead of LaTex. However, this is
a lot of work to code too.

It sounds like you are proposing more of a CLI-based cartography module
(conceptually along the lines of LaTex perhaps?). If so, why not work with
improving the existing CLI cartographic module, ps.map? Make it easier to
use so that it can be realistically be controlled interactively from the
CLI. Just a thought.

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