[GRASS-dev] Wxpython gui update

Jachym Cepicky jachym.cepicky at centrum.cz
Mon Aug 14 04:21:03 EDT 2006


hi Michael,

it works nice, thanks, 

one small problem: draging does not stop - you can not ged rid of that
function and anywhere you click on the screen (the whole screen, not
only the map monitor), you are continuing to draging

adding self.EndDrag() makes it work right (in debian)

    def DragMap(self, moveto):
        '''drag a bitmap image for panning.'''
        dc = wx.BufferedDC(wx.ClientDC(self), self._Buffer)
        dc.SetBackground(wx.Brush(self.GetBackgroundColour()))
        bitmap = wx.BitmapFromImage(self.img)
        self.dragimg = wx.DragImage(bitmap)
        self.dragimg.BeginDrag((0,0), self)
        self.dragimg.GetImageRect(moveto)
        self.dragimg.Move(moveto)
        dc.Clear()
        self.dragimg.DoDrawImage(dc, moveto)
        #####################
        # here it is
        self.dragimg.EndDrag()

jachym




On Sun, Aug 13, 2006 at 11:23:07PM -0700, Michael Barton wrote:
> 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
> 

> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev

-- 
Jachym Cepicky
e-mail: jachym.cepicky at centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------   
OFFICE:                                     
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky at gdf-hannover.de
URL:    http://gdf-hannover.de
Tel.:   +49 511-39088507
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20060814/fa38c5b6/attachment.bin


More information about the grass-dev mailing list