[GRASS5] v.transform semi-error

[Glynn Clements]

Markus Neteler wrote:

> > > > Happy to try to clarify now I that I've figured out why I've been 
> > > > confused. When you use v.transform from the tcltk menu system, it says 
> > > > to input an ascii vector map. If you click the browse button (labeled 
> > > > "vector_ascii", as is the output map name browse button), it goes to 
> > > > the dig_ascii to search for a map. If you select a map from there it 
> > > > appears in the dialog window. However, when you try to run v.transform 
> > > > (clicking the "run" button) it says file not found.
> > > > 
> > > > The problem seems to be that the tcltk menu system has not been updated 
> > > > to reflect changes in v.transform. In the manual, it says binary vector 
> > > > file and v.transform from the command line works as specified there.
> > > 
> > > OK, I have fixed that in tcltkgrassi (but didn't test).
> > > 
> > > That's why 5.7 renders the menus automatically, no such update work :-) 
> > 
> > How does it deal with the issues surrounding r.colors, as discussed in
> > the "Testing Grass 5.3" thread?
> 
> I think it doesn't.
> So I change my statement to 
> "minimized update work with few outstanding issues".
> 
> You are welcome to suggest a solution.

More precisely, how does it decide if the program requires an xterm?

If it always requires one, that trivially solves the problem.

One option for dealing with the fact that r.colors sometimes requires
a terminal but usually doesn't would be to remove the color=rules
facility from r.colors and create a separate r.colors.rules program
for that case.

A couple of other points:

1. I already noted that the method of having multiple menu items (and
module files) for a single program was already being used for
v.support; presumably that won't work either. More generally,
auto-generated menus/dialogs won't work particularly well for programs
which have multiple "modes". Again, one solution is to split such
programs into several more specific components.

2. I'm wondering how many programs support using stdin as the input
file but don't have the "requires an xterm" flag set in their
(5.0/5.3) tcltkgrass module file.

3. More generally, if you want to make programs GUI-friendly, you need
to stop assuming that stdin exists. That includes use of "infile=-",
G_ask_*(), Vask etc.

-- 
Glynn Clements <glynn.clements at virgin.net>