[GRASS-dev] Re: GRASS startup window patches

Paul Kelly paul-grass at stjohnspoint.co.uk
Sat Jan 6 16:46:42 EST 2007


Hello Maris
This looks good, and useful. I didn't realise Michael had added a 
location-list refresh function, but glad to see you've usefully added it 
after the "Create from projection values" button returns from running 
set_data and g.setproj. I think I will change it so a pop up terminal 
Window appears on both Unix and Windows for this - I really think it would 
be more useful than exiting back to the terminal the GUI was started from 
- on Windows for example this might not even exist!

I still had difficulties getting your patch to apply cleanly though:
sh-2.04$ patch -p0 </c/temp/gis_set.patch
patching file `lib/init/gis_set.tcl'
Hunk #1 FAILED at 162.
Hunk #2 FAILED at 194.
Hunk #3 FAILED at 250.
Hunk #4 FAILED at 264.
Hunk #8 FAILED at 665.
Hunk #11 succeeded at 744 (offset 18 lines).
Hunk #12 FAILED at 763.
Hunk #13 succeeded at 752 (offset -18 lines).
Hunk #14 succeeded at 853 (offset 18 lines).
Hunk #15 succeeded at 830 (offset -18 lines).
6 out of 15 hunks FAILED -- saving rejects to lib/init/gis_set.tcl.rej

but as you suggested these all turned out to be whitespace issues (I only 
checked the first hunk - there was what looked like a blank line, but in 
the original source it actually contained 4 spaces whereas in the patch it 
was completely empty) and I was able to work around them by using the -l 
switch with the patch command.

One thing I wanted to ask: where you wrote:
global database location
did you really mean there to be two separate global variables, database 
and location? The documentation at 
http://www.tcl.tk/man/tcl8.4/TclCmd/global.htm suggests that each variable 
should be on a separate line, i.e.
global database
global location
but I'm not 100% sure.

Apart from those issues it looks good and could be committed I think. I'm 
not sure about the location and mapset names.

Paul

On Sat, 6 Jan 2007, Maris Nartiss wrote:

> Hi all of You!
> I was not going to spawn such discussion, but it's damn good, as,
> hopefully, it will make GRASS more lamer friendly :)
>
> I have to apologizes about forgetting describe my patches. In my mind
> I was already looking how to fix other GRASS startup screen issues
> (Yes, there still are some of them) and forgot to tell everyone about
> what I'm doing. My apologies to all of you.
>
> I recreated gis_set patch with -b option, as it seems, that my text
> editor (kate) has set to strip whitespace at end of lines thus ending
> in unnecessary changes. Sorry about that. I still have to learn all
> that dev stuff :)
> As Michael has introduced refresh_loc procedure to refresh location
> list as result of any changes, I changed all places that had own
> location refresh code to use new location refreshments code.
> Second thing - previous code was safely expecting, that "cd" will
> never fail. I added new procedure to catch "cd" errors.
> Test yourself: cd GISDBASE && chmod -x LOCATION && grass63 && play around
>
> One HUGE startup screen issue is still remaining (aside from new
> location creation) - user can enter as mapset/location name
> characters, that will NOT be supported by GRASS (i.e. mapset with
> UTF-8 coded character). That's why I wrote email about what is allowed
> in location/mapset/map names and what is not [1]. Please, take 5 mins
> of your precious time to answer. Thank You!
>
> Thank you all for your great work and let's try to make GRASS pass
> "The Monkey" [2] test :)
>
>
> Maris.
>
> [1] http://grass.itc.it/pipermail/grass-dev/2007-January/028360.html
> [2] 
> http://www.folklore.org/StoryView.py?project=Macintosh&story=Monkey_Lives.txt&sortOrder=Sort%20by%20Date&detail=medium
>




More information about the grass-dev mailing list