[GRASS-dev] Shell scripts

[Dylan Beaudette]

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.

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