[GRASS-dev] GRASS startup window patches

[Paul Kelly]

Hello Maris,
A few points:
It's a bit hard to see what your patch does by looking at it - there seem 
to be a lot of bogus changes where the line deleted and the line added are 
the same - could it be an issue with Tab/space conversion settings in your 
editor perhaps?
You don't need to put a changelog as comments in the file - it is saved 
automatically when commited to CVS!

As we saw in the discussions about g.region and gis.m, using the Tcl catch 
commands on GRASS commands isn't generally a good idea as Tcl falsely 
assumes a command that writes to stderr is issuing an error. This applies 
to g.proj too. If partially-specified datum information is passed to 
g.proj, it WILL try to interactively prompt the user for complete 
information. This is done by printing to stderr and looking for an input 
on stdin.(The Tcl catch command will treat this as an error.) There are 
also circumstances where g.proj will issue a warning (but still proceed to 
create the location OK), and again this writes to stderr and the catch 
command will erroneously assume there is an error.

I think, until we can work out some way of always passing fully specified 
datum information to g.proj, that when g.proj is used for location set-up 
we should run it in a pop-up terminal Window. So if it does choose to 
prompt the user it (while kludgy and archaic-looking) will actually work. 
The procedure run_xterm in lib/gtcltk/gronsole.tcl has some Unix/Windows 
Tcl code for running GRASS commands in a pop-up terminal Window (it would 
be good to have this in a function for use by all the Tcl bits of GRASS, 
not just those that use gronsole, but I'm not sure how to do that).

But yes as you said below about using g.proj to create a new location 
using a georeferenced file - that is exactly the same idea as using the 
EPSG code. In fact better, as the recent update I made to g.proj a few 
days ago now attempts to set initial region settings for the new location 
from the extents of the file (using code taken from r.in.gdal and 
v.in.ogr). I haven't really tested it yet though.

Helena made the point that it was important to impress the concept of 
setting the initial region for a location on the user, and that this was 
lost a bit with the new "one click" location creation. I was thinking, 
that it would be a good idea for the start-up GUI, after the location was 
created, to read the region back in (using g.region probably) and then 
present this to the user in a GUI screen similar to the curses-based 
region setting that the old inter version of g.region used to have. If the 
region had been set from a georeferenced file, it would probably be fine 
and the user could just press OK, or if the location had been created e.g. 
from an EPSG code there would just be a default 1pixel-sized region that 
the user could then set. If a pretty GUI screen was created for this it 
could also be used for setting the region in gis.m proper - the current 
straight-down list of north, south, east, west, resolution etc. is 
inferior IMHO to the old interactive terminal-based g.region.

Before Christmas when I changed g.proj to call G_no_gisinit() instead of 
G_gisinit(): that removed the issue whereby a whole template location with 
valid mapset had to exist before actually creating a new location with 
g.proj - now it just needs a GISRC file with the GISDBASE field set to 
something valid. HOWEVER, the G_tempfile() issue (which does require a 
valid current location and mapset) hasn't yet been fixed, so can't remove 
all that stuff out of epsg_option.tcl just yet. But I will try and get the 
time to propose something to the list soon and we can sort it out.

This e-mail has just been a bit of a brain-dump really, sorry about that

Paul

On Fri, 5 Jan 2007, Maris Nartiss wrote:

> Hi all,
>
> as last night I had loooong chat with some first time GRASS user, who
> was hit by problems in GRASS startup screen (paritaly fixed in 6.3),
> thus today I spent some time on fixing small usability problems of
> startup screen.
>
> Please, somebody review them and commit to CVS.
>
> And another question - epsg_option.tcl uses "exec g.proj" to call
> g.proj. Is possible (safe) to use same approach to create new location
> from georeferenced file? If yes, then it's just copy/paste epsg_option
> code and a bit to tweak to make georef location creator as same good
> like epsg one :)
>
> Maris.
>