[GRASS-dev] grass and python

[Michael Barton]

Trevor,

The current prototype at least partly solves these issues.

You can now issue multiple d.* commands, separate by commas on the CLI.
These are parsed into a list of d.*  commands and processed in a loop.

Try d.rast elevation_dem, d.vect streams color=blue

Also, any d.* commands are now processed for display into whichever map
display has the focus. Try opening a second display and typing some
different d.* commmands; click on the first display and type some new d.*
commands.

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



> From: Trevor Wiens <twiens at interbaun.com>
> Date: Fri, 11 Aug 2006 21:55:47 -0600
> To: William Kyngesburye <kyngchaos at kyngchaos.com>
> Cc: <woklist at kyngchaos.com>, Michael Barton <michael.barton at asu.edu>,
> <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] grass and python
> 
> This is a good question and there has been some off list discussion
> about this. What I've researched and am (very slowly implementing) is a
> way to wrap the shell within the python GUI (optionally) so that users
> will be able to use the shell of their choice with the new GUI.
> Obviously a python shell would be default, but bash, etc would be
> available. Together with this I'm planning on building a socket based
> interface to the display tree that will be callable with a few simple
> commands from whichever shell the user chooses. The advantage over the
> existing display architecture is that it will be possible to manipulate
> the display layers and redisplay from command line without having to
> reissue each draw command. Another advantage is that the command line
> use and the GUI are synchronized. One of the strengths of the new
> gis.m is that you can have different views of the same data in
> different windows but the difficulty for CLI based users is that
> one can't EASILY manipulate those views from CLI. I'm trying to solve
> this problem as well as make CLI use more elegant and GUI programming
> simpler. At this point nothing is implemented as I'm in the research
> and planning stage.