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" <[EMAIL PROTECTED]> 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 _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
