[GRASS-dev] Wxpython gui update

[Michael Barton]

I just put up new files (mapdisc.py, gism.py, and render.py) on my website.

I rewrote the display as a double buffered dc drawing. I HOPE this solves
the display issues with Linux. Thuban seems to use a somewhat more primitive
version of this, so I¹m keeping my fingers crossed. Please let me know. If
it works, I¹ll package it all up for the last time and note it on the WIKI.
Then I hope to move it to the cvs so all you can work on it.

I also added a couple new bells and whistles. By redoing the display to use
a bufferedDC, it is easy to make graphic file output. Using a simply example
from the wxPython cookbook, I added output to PNG files. It is easy to add
other formats.

With regards to the discussion about postscript, wxPython has a wx.PrinterDC
and wx.PostScriptDC, that will output to postscript.

I also have set it so that you can specify the pen for mouse drawing in the
event handler for a display control button. As example, zooming in and out
have different colored zoom-rectangles.

Currently, the little command line shell allow you to chain display
commands. It simply puts them in a list and processes them in the order of
the chain. You could make something more sophisticated like having add
[command] and delete [command] to add them to a list, but this soon gets
complicated (e.g., rearranging display commands in the list to control how
they are rendered may be simpler by just cutting and pasting them in a chain
rather than trying to remember where they are and doing a move or insert).
You also have to watch out for possible conflicts with Œreal¹ shell
commands.

It¹s still not clear to me what is gained by starting in a Bash shell,
starting the python app, and have it listen for special commands coming from
the shell that it can recognize and parse. Why not simply start in a python
shell that can send any shell commands to the shell (whatever shell you
want; this too can be set by a command or a default from a config file) and
trap the 350 or so GRASS commands? Same effect and easier to code and
control. Maybe I¹m missing something.

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: David Finlayson <david.p.finlayson at gmail.com>
Date: Sun, 13 Aug 2006 21:47:16 -0700
To: Glynn Clements <glynn at gclements.plus.com>
Cc: Trevor Wiens <twiens at interbaun.com>, Michael Barton
<michael.barton at asu.edu>, <grass-dev at grass.itc.it>, <William at grass.itc.it>,
Kyngesburye <kyngchaos at kyngchaos.com>, <woklist at kyngchaos.com>
Subject: Re: [GRASS-dev] grass and python

The Python interpreter is interactive, but it is not a general purpose
shell. You would need to wrap external programs in an os.system or os.popen
call. One attractive way of getting around this is to pre-wrap each program
in a python object. For example:

class Display:

    def rast(self, rastername):
        os.system("d.rast %s" % rastername)

Then the syntax in the Python interpreter would be:

> import Display
> d = Display.display ()
> d.rast(rastername)

Which isn't so bad. This is what things would look like in PyShell (or
PyCrust) which is a wxWindows-compatible python interpreter that you can use
in wxWindows GUI's.

The most advanced Python interpreter is IPython. This has been tweaked for
interactive use by the Scipy (numeric programming) folks so that some of the
Python decorations can be dropped in the above example:

> import Display
> d = Display.display()
> d.rast rastername

No more parenthesis needed. Also, IPython has "magic" operators that allow
you to "shell-out" to the underlying shell. Simply prepend a command with a
% and it will bypass the python interpreter and send it to the shell:

> %ls

or

>%dir

The IPython interpreter is designed for interactive use. It is the Scipy
answer to Matlab's interactive prompt. It has a lot of nice shell-like
features and can be extended for use by GRASS (I think). Unfortunately, I
don't think IPython is as well integrated with Windows as Unix. At least on
my casual observations.

David

On 8/13/06, David Finlayson <david.p.finlayson at gmail.com> wrote:
> The Python interpreter is interactive, but it is not a general purpose shell.
> You would need to wrap external programs in an os.system or os.popen call. One
> attractive way of getting around this is to pre-wrap each program in a python
> object. For example:
> 
> class Display:
> 
>     def rast(self, rastername):
> 
> 
> 
> 
> On 8/12/06, Glynn Clements < glynn at gclements.plus.com
> <mailto:glynn at gclements.plus.com> > wrote:
>> 
>> Trevor Wiens wrote:
>> 
>>>> > > If anyone can find a real language which is "good enough" on all of
>>>> > > Unix, Windows (Cygwin and native) and OSX, I'll quite happily rewrite
>>>> > > all of GRASS' shell scripts.
>>> >
>>> > Python is easy to install on Windows. So with an offer like that, I
>>> > can't help asking if any of the interactive Python shells are to your
>>> > knowledge good enough. Or perhaps what in you mind defines an
>>> > interactive shell environment that is good enough to replace bash?
>> 
>> The main issue is the ability to have scripts which can be run as e.g .
>> "d.save", and not having to use "d.save.py <http://d.save.py> ". This needs
>> to work both
>> from a shell and from system/exec/popen/spawn/etc functions provided
>> by various languages.
>> 
>> --
>> Glynn Clements <glynn at gclements.plus.com>
> 
> 
> 
> -- 
> David Finlayson 



-- 
David Finlayson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20060813/64ba5db0/attachment.html