[GRASS-dev] Shell scripts

[Michael Barton]

On Nov 30, 2009, at 1:38 PM, Dylan Beaudette wrote:

> On Monday 30 November 2009, Michael Barton wrote:
>> If you take a look at histogram.py, this gives some idea of what it
>> takes to create a module that renders in wxPython canvas. You can
>> eliminate the code for drawing the histogram window and tool bar, of
>> course, but there is still quite a bit of coding to do to run d.hist
>> and have the results rendered in the canvas.
>>
>> Something along this line could potentially be written to make it
>> possible to display something in the canvas by typing a command of
>> some sort from the terminal. But I was wondering if it would be
>> simpler to display maps in another way for those who want to work in
>> this way.
>
> I think that this would be a great idea. I tend to share Markus'  
> concerns
> about preservation of the d.* commands. I agree that these are based  
> on an
> antiquated model of displaying information, but the concept is quite  
> elegant
> and in some ways superior to a GUI-based system. Perhaps there is a  
> way to
> leverage the canvas from the command line, without having to 1) re- 
> invent the
> wheel, and 2) duplicate efforts in the GUI. I understand that my  
> ratio of
> complaining : coding is not ideal-- so I would be willing to help  
> test any
> such mechanisms as they progress.
>
>> Also, did you know that you can type a d.vect or d.rast in the
>> wxPython command console to add a map layer? Maybe a better way to go
>> is to improve the wxPython command console with history, etc. than to
>> create a separate interface.
>
> OK. Well, this is getting closer to what the purists among us would  
> like, but
> having this functionality in the console-- not the wx-based  
> console-- is
> important.

Dylan,

I guess the point I was trying to make was that if some of the Linux  
folks don't want to use the GUI at all, but prefer to control GRASS  
entirely by typing commands in the system terminal, I think that it is  
easier to design a display mechanism from scratch and not bother  
trying to use the wxGUI canvas. That is, I'm not convinced that trying  
to "leverage" the wxGUI canvas won't be considerably more difficult  
than an alternative method from the system terminal. There is a lot of  
complex code in the GUI canvas and related wxPython modules to do  
composited rendering in an interactive environment that is not needed  
for simply displaying maps by typing commands. A solution focused on  
the system terminal is indeed a 'purist' one for Linux users, but  
probably won't be of much interest to most users outside of the Linux  
world and maybe not even to all Linux users.

Right now, you can set the following environment variables and run any  
d.* command to have an output file created of the map to be displayed.

GRASS_PNG_AUTO_WRITE = TRUE
GRASS_PNG_READ =FALSE
GRASS_TRUECOLOR = TRUE
GRASS_RENDER_IMMEDIATE = TRUE
GRASS_WIDTH  = [value]
GRASS_HEIGHT = [value]

GRASS_CAIROFILE = [outputfile]
GRASS_PNGFILE = [outputfile]

For example, we have added functionality to NASA WorldWind that will  
display PNG files created in this way. Other viewing utilities could  
also be used even more easily, and the whole thing wrapped into a  
python script.

On the other hand, if these folks DO want to use the wxPython GUI (and  
all the interactive tools on the canvas) but simply want to be able to  
get maps displayed in the canvas by typing commands instead of adding  
them to the layer manager, then I think the better way to go is to  
enhance the wxPython console. This solution could be of interest to  
power users on all platforms.

Michael


>
> Cheers,
> Dylan
>
>
>> Michael
>>
>> On Nov 27, 2009, at 12:33 AM, Markus Neteler wrote:
>>> On Fri, Nov 27, 2009 at 2:56 AM, Glynn Clements
>>>
>>> <glynn at gclements.plus.com> wrote:
>>>> Michael Barton wrote:
>>>>>> If you want to be able to control the GUI from the command line,
>>>>>> that
>>>>>> should be dealt with as an infrastructure issue, not by creating
>>>>>> wrappers around individual commands.
>>>>>>
>>>>>> I can deal with the display/driver libraries, and with generic
>>>>>> Python
>>>>>> IPC, but some of it will need the involvement of someone who
>>>>>> understands the GUI.
>>>>>
>>>>> Winter break is near and I'll be laid up for a week. So I might be
>>>>> able to help.
>>>>>
>>>>> Controlling the GUI from the command line is a contradiction in
>>>>> interface terms. Perhaps you really mean displaying a map from the
>>>>> command line?
>>>>
>>>> I mean controlling the GUI, i.e. being able to modify the list of
>>>> displayed maps. That's what the p.* scripts appear to be doing.
>>>
>>> Yes, like what the d.* commands did with x0 etc.
>>> I regularly enjoy the beauty of shell history which I would
>>> not have using the (pure) GUI since clicks aren't registered.
>>>
>>> Markus
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
>
> -- 
> Dylan Beaudette
> Soil Resource Laboratory
> http://casoilresource.lawr.ucdavis.edu/
> University of California at Davis
> 530.754.7341