[GRASS-dev] GRASS startup window patches

Michael Barton michael.barton at asu.edu
Sat Jan 6 12:03:57 EST 2007


Paul and Maris,

I missed this message, but will try to catch up on responding to a few
items.


On 1/5/07 2:06 PM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:

> 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!

Most of the epsg_options.tcl.in patch seems to be for internationalization.

> 
> 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).

Maybe for the moment, it would be best to add Paul's new code (done for
mapcanvas.tcl last night) for stderr to this at the moment. Maybe the popup
warning that Maris put in can be parsed OK, but I guess I'll need to look at
it. I'm not in favor of using an interactive terminal for the reasons I've
expressed before and Glynn's recent comments. I think the gronsole code is a
bit misleading in this respect. It does allow you to run commands from a
command line. It's the interactive part that doesn't work.

> 
> 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.

The updates I did last night should make it possible to test this more. It
seemed to work for me.

> 
> 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.

It's pretty easy to make a TclTk interface that mimics the curses-based one
if this is desirable. The basic information from g.region can be put in the
fields and allow the user to edit it. Dealing with projection information is
much more complicated, which is why I haven't yet tackled a complete TclTk
replacement for g.setproj.

> 
> 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.

I've made it so that creating a fake location can be pretty easily stripped
out of epsg_option and file_option scripts.

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

A very helpful one. Thanks for all that both of you have been doing on this

Michael

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

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





More information about the grass-dev mailing list