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

[Michael Barton]

Glynn,


On 6/12/07 8:58 AM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

> 
> Michael Barton wrote:
> 
>> d.rast.edit ought to run from wxgrass, assuming that TclTk is installed. It
>> launches the wxPython properties dialog when called from the menu. However,
>> the wxPython properties dialog, then launches the TclTk properties dialog
>> instead of just running the command (note that running d.rast.edits with
>> arguments runs fine from the wxgrass built in CLI).
>> 
>> The place where the command is getting rerouted to call the TclTk dialog
>> seems to be in line 636 of menuform.py
> 
> It's being treated as a layer because it begins with "d.".
> 
> The "d.*" hack is a bad idea; I suggest that you remove it.

I'm not sure why the d.* clause is in this particular place--one reason to
query Daniel who has done most of the work making menuform work well.

We need to split out d.* commands elsewhere because they must be processed
differently from other commands in order to show up in the display canvas,
but this would not apply to d.rast.edit. It is the only command that I know
of that would handle it's own display still.

> 
>> retcode = subprocess.call(cmd, shell=True)
> 
> Why are you using a string instead of a list?

I looked at cmd coming in and I think it is a list.

> 
>> Any idea why this might be? I could hack around this for the one command,
>> but there should be a more generic solution it seems.
>> 
>> BTW, I got the xterm launching method to work by using
>> subprocess.Popen(cmdlist) for starting the needed xmon ['d.mon',
>> 'start=xmon']. Both cmd.Command(cmdlist) and cmd.Command(cmdlist,
>> wait=False) didn't work and hung up waiting on the xmon. Don't know why.
> 
> Personally, I suggest not bothering with interactive d.* commands.
> wxgrass isn't going to be stable until 7.x (apart from anything else,
> wxPython 2.8 isn't going to be in widespread use before then), so I
> don't see much point in making an effort to support features which
> will have been removed by then.

Well, my idea was to simply make it possible to call the few remaining
commands like nviz d.rast.edit, that still need TlcTk canvases, and ones
that still need an xterm, rather than really supporting them (i.e., no
further development on their interfaces the way they are now). That way
their functionality remains available while we work to replace them with
wxPython. Kind of smoothing the transition somewhat.

It should be possible to port d.rast.edit (or its functionality) to
wxPython, since it is TclTk, at which time we'd just change the call in the
menu to aim at the new one. Nviz launches fine, as do the xterm commands.
d.rast.edit is the only one that doesn't launch quite right. It's not a
biggie, but if it is an easy fix, it would be nice.

Michael


__________________________________________
Michael Barton, Professor of Anthropology and 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