[GRASS-dev] d.rast.edit in wxgrass

[Michael Barton]

Paul,

Others have answered while I was away, but I'll add a few clarifications
below.


On 6/16/07 2:33 AM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:

> On Wed, 13 Jun 2007, Michael Barton wrote:
> 
>> GRASS command parsing from the wxgrass CLI:
>> 
>> Split the command into a list by spaces. I realize that this is a problem
>> for any command with spaces in the arguments, but I know of no better way to
>> do this in this context outside of making users type any command as a Python
>> list. If we made people type ['g.region', 'rast=mymap', 'res=30'] instead of
>> g.region rast=mymap res=30, I don't think anyone would want to use the CLI.
>> 
>> If the command has no arguments (i.e., len(cmdlist) == 0) AND it is NOT a
>> d.* command, send the original command string (not the list) to the
>> menuform.py processor (just like the menu would) to create the autogenerated
>> properties dialog. After this, the result of hitting "run" is the same as if
>> the properties dialog were called from the menu.
> 
> I don't get why it needs to do that specific processing - can you not just
> run whatever is entered - if a command is run without arguments it will
> pop up the GUI dialog anyway. Unless GRASS_UI_TERM is set. I suppose at
> the minute it will always be a Tcl/Tk dialog that pops up, but I'm sure it
> wouldn't be very hard to change G_parser() to check the GRASS_GUI variable
> (or do something similar) and generate the correct autogenerated dialog
> corresponding to the GUI that's in use.

Ultimately, it would be nice if the wxPython parser is used automatically if
GRASS_GUI = wx in the .grassrc6 file. Until that time, we need to manually
send all commands to the wxPython parser in this way.

> 
>> If the d.* command without arguments is NOT on the list for the layer tree,
>> generate get a message that it cannot be processed.
>> 
>> If the command HAS arguments and is NOT a d.* command, send the command list
>> (i.e., made by splitting on spaces -- not the original command string) to
>> cmd.Command for processing.
> 
> I think Glynn commented on this in a later mail but could you not just
> take the whole string the user entered and pass it to the shell (or
> cmd.exe on Windows) for executing - that way all the quoting rules etc.
> that work in the shell will be consistent with how it works here and
> reduce user confusion, and avoid you having to implement quoting handling
> yourself in the space-splitting algorithm..

Right. This is a sub-optimum solution, but needed at the present (i.e., it
must be split into a list to run with cmd.Command). But Glynn offered some
ideas on how to improve on this.

> 
>> If the command HAS arguments and IS a d.* command, it is added to the list
>> of display layers managed within render.py for the map display that has the
>> focus and the UpdateMap method is called to update that display. There is a
> 
> That's a nice idea. I didn't realise it was so easily possible. Is it
> possible to edit a display layer by editing the underlying raw d.*
> command-line that it corresponds to, as an alternative to ticking boxes?
> There obviously must be code to convert the GUI representation of the
> layer to  d.* command-line for drawing, and it sounds like you now have
> new code to parse the d.* command-line and convert it to a GUI
> representation (i.e. the display layer), so allowing editing of a layer by
> changing the raw command-line it uses should be possible.
> 
>> 2nd splitting that allows for multiple d.* commands to be separated by
>> semi-colons. This may or may not be a good idea in the end, but I thought
>> I'd see how it worked out.
> 
> Shell uses semi-colons. But you could you not just enter the two commands
> separately one after the other? I suppose if it was something that would
> take a long time to draw then that would be slow.

The problem is that you need a defined separator that indicates where one
command AND its arguments stop and another one starts. You could perhaps
look for another "d." string, but a defined separator is easier to use and
perhaps more reliable.

> 
> All sounds good. I like the idea of the GUI having command-line features
> and most of the command-line functionality being still available should
> you need it. You could call it power-user features I suppose.
> 
Thanks. Glad it is worth the effort to make this work.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton