[GRASS-dev] Wxpython gui update
Michael Barton
michael.barton at asu.edu
Mon Aug 14 11:07:28 EDT 2006
OK. So the answer is that I don't have to explicitly handle the end drag.
Just put it in and it knows what to do.
Thanks to both Jachym and Moritz. I reposted mapdisp.py with this fix. Also
thanks to Jachym for suggestions about how to make the zoom box look the way
it should.
I'm VERY glad that the disappearing display is fixed.
With regard to the black startup screen. It's not the background setting but
displaying an empty image on startup. I'm sure it's fixable, I just haven't
figured out exactly how/where yet. If you guys find it, we should put it in.
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: Jachym Cepicky <jachym.cepicky at centrum.cz>
> Date: Mon, 14 Aug 2006 10:21:03 +0200
> To: Michael Barton <michael.barton at asu.edu>
> Cc: David Finlayson <david.p.finlayson at gmail.com>, Glynn Clements
> <glynn at gclements.plus.com>, Trevor Wiens <twiens at interbaun.com>, William
> Kyngesburye <kyngchaos at kyngchaos.com>, Moritz Lennert
> <mlennert at club.worldonline.be>, Yann Chemin <ychemin at gmail.com>,
> <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] Wxpython gui update
>
> 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
More information about the grass-dev
mailing list