[GRASS-dev] Re: GRASS startup window patches

[Maris Nartiss]

Paul, that documentation does not say anything about being able to use
only one variable per global declaration. And gis_set.tcl already had
multiple variables per global keyword. And finaly - it works with
tcl/tk 8.4.

Please, use second gis_set.tcl patch I sent - I added two more lines
to set $location to blank, if GISDBASE is changed. Previously it wuold
leave $location unchanged and thus be source of bug (change GISDBASE
directory to empty dir, create new mapset an it will try to create one
eaven if there are no locations, as $location contains old value). I
also added "-nocomplain" flag for location refreshment's code to get
around empty location list creation.


On Linux with tcl-8.4.13 creating new location from EPSG code always
returns to startup screen. No "start session with new location by
default". If it acts differently on Mac, then it is an error. I do not
own Mac and I do not know any of my freands with Mac (Mac's are not
popular in my country) and thus I will not be able to help with
debuging :(
During my code hacking going stright to GRASS session and not to
startup screen allways was result of (my) error and not result of
normal action. In Konsole (KDE xterm like app), I still had tcl error
messages in scrollback buffer - just a matter of scrolling window up
to see errors.


Maris.

2007/1/7, Michael Barton <michael.barton at asu.edu>:
> Now that I know what the changes attempt to do, I tried it out. In my case
> at least, after making a new location, it went straight into GRASS. It
> didn't return to the startup screen so that the user could decide to use or
> not use the new location.
>
> This is not due to Maris' changes, but to the way the startup worked in the
> first place. Gis_set.tcl doesn't seem to even run g.setproj. It looks like
> it returns to init.sh for this. I'm not exactly sure why it is writing a
> bunch of values to stdout just prior to this either. Is it trying to set
> some environmental variables for init.sh?
>
> I don't mind committing this, but it seems like we ought to do a bit more
> first. What about having gis_set.tcl do the running of g.setproj and then
> return to the refreshed startup? This seems like a better, more consistent
> way to go.
>
> Michael
>
>
> On 1/6/07 2:46 PM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:
>
> > Apart from those issues it looks good and could be committed I think. I'm
> > not sure about the location and mapset names.
> >
>
> __________________________________________
> 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
>
>
>