[GRASS-dev] grass and python

[William Kyngesburye]

On Aug 11, 2006, at 10:55 PM, Trevor Wiens wrote:

>> 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.
...
> simpler. At this point nothing is implemented as I'm in the research
> and planning stage.
>
Cool.  I'll wait to see what you come up with.

>> 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.

Right, understood...

> 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.
>
... But, yes, a Mac application normally only can run in one  
instance.  So the application would have to be able to handle working  
with multiple working mapsets.  We'd have to figure out what a  
'document' would be, like a working environment, connected to a  
single mapset, which can have one or more displays/views, command  
windows, a log window, like the GUI is now (can it have more than one  
display?).  Keeping them connected visually so the user knows which  
window belongs to which environment might be tricky (it already is  
when there is more than one GUI running).

Maybe a single-document workspace idea might be better - have a  
single window with panes for the various parts, kinda like the NVIZ  
window.  Each window object can easily keep track of its own  
environment.

-----
William Kyngesburye <kyngchaos at kyngchaos.com>
http://www.kyngchaos.com/

Earth: "Mostly harmless"

- revised entry in the HitchHiker's Guide to the Galaxy