[GRASS-dev] grass and python

[Trevor Wiens]

On Fri, 11 Aug 2006 11:19:48 -0500
William Kyngesburye <woklist at kyngchaos.com> wrote:

> I've been working on an alternative Mac GRASS.app startup - currently  
> it uses the OnMyCommand droplet as an app template, but I'm looking  
> for a more open source, buildable kind of startup, and found py2app.   
> (Lorenzo's AppleScript Studio method could work, but I don't want to  
> have to deal with Xcode.)
> 
> I have something that works, but it got me thinking about the  
> wxpython gui developments.  I haven't been paying much attention to  
> that and haven't had a chance to try it yet.  So, py2app offers a  
> cool possibility - a completely selfcontained Mac application, and  
> its cousin py2exe might do the same for Windows.
> 
> My question is, does, or is it possible in the future for, wxpython  
> grass to start directly from 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. 

> Or like the tcltk GUI, does it  
> need the GRASS shell running first for the initial environment  
> setup?  It would be nice for the wxpython GUI to setup and maintain  
> the environment that init.sh does.  Then it could let the user open a  
> Terminal or other shell (maybe a pseudo-terminal within python?) to  
> run commands the old fashioned way if desired, but not require that.   
> Also, it would keep a persistent 'GRASS.app' application in the Dock  
> while 'GRASS' is running.
> 
> My current python startup app just fires up the normal init.sh  
> startup and quits, leaving GRASS running in the Terminal and the GUI  
> in TclTk X11, and disappears from the Dock.  While the OnMyCommand  
> method at least stays around in the Dock until GRASS is quit from the  
> Terminal (even tho it doesn't do anything after starting GRASS, it's  
> nice to have that visual clue in the Dock that GRASS is running).
> 
> Another question about the wxpython GUI - does or will it handle  
> multiple GRASS sessions at once, kind of like having multiple  
> documents (ie mapsets) open in an application?  

>From my point of view, this idea conflicts with GRASS architecture.
Still, if for Mac users running multiple instances was desirable but
problematic as the application wouldn't be shell dependent, it would
be possible to program the facility to open another copy of the GUI for
another mapset. Hmmm...  Perhaps it might be useful to think of what
functionality this would achieve and then think if there is a more
elegant solution, such as gis layer (not in the convoluted vector
terminology sense) file browser which would enable one to look at
other mapsets, etc. Associated with such a GUI tool would obviously
come copying and reprojection, but since I'm not sure what you are
thinking of, this idea may be way off base.

> A Mac application  
> normally can only open in one instance, unlike running different  
> instances from multiple Terminal windows.  I just realized that my  
> current OMC app can only run one at a time, since the app stays open,  
> yet the python method I'm working on can open multiple instances of  
> GRASS, since the app itself quits right away, leaving GRASS running  
> (a bit confusing for a Mac user, and especially so since there is no  
> hard connection between the GUI and the Terminal shell that opened it).
> 
> One nice thing about the py2app setup is that it can locate and  
> create local copies of all dependencies (python modules and dynamic  
> libraries and frameworks) needed plus a minimal copy of the python  
> runtime environment.  Then the user doesn't have to worry about which  
> Python they have installed, that might be too old or too new, or  
> having all the needed modules installed.  With the current init.sh  
> startup, it would have a hard time locating dependencies for this  
> since it doesn't really 'see' the internals of the wxpython grass  
> gui, though it might since it seems to be pretty rigourous in  
> identifying stuff like that.
> 
> -----
> William Kyngesburye <kyngchaos at kyngchaos.com>
> http://www.kyngchaos.com/

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)