[GRASS-dev] Re: [grass-code I][478] tcl/tk gui startup screen launches grass even when 'Exit' is pushed

[Moritz Lennert]

On 24/09/07 19:55, grass-dev at grass.itc.it wrote:
> code I item #478, was opened at 2007-09-07 15:40
>> Status: Open
> Priority: 3
> Submitted By: Moritz Lennert (moritz)
> Assigned to: Māris Nartišs (marisn)
> Summary: tcl/tk gui startup screen launches grass even when 'Exit' is pushed 
> Issue type: other bug
>> Issue status: confirmed
> GRASS version: CVS HEAD
> GRASS component: startup
> Operating system: Linux
> Operating system version: 
> GRASS CVS checkout date, if applies (YYMMDD): 070903
> 
> 
>> Comment By: Maciej Sieczka (msieczka)
> Date: 2007-09-24 19:55
> 
> Message:
> The issue is more complicated. According to Paul Kelly the committed fix is not complete. See Details Below:
> 
> 


Where are we at with this issue ? At this point it is still not solved 
for wingrass and for other platforms I don't know if the solution 
currently in CVS for init.sh is deemed satisfactory.

Moritz

> 
> Paul Kelly wrote on GRASS dev ML:
> 
> 
> 
>> I think it's a good idea to change the behaviour here,
> 
>> but I feel the patch doesn't really address the problem:
> 
>> rather it adds more code to work around it. In
> 
>> particular, clicking exit in the gis_set.tcl Window won't
> 
>> work with init.bat (Windows) now, as it used the exit
> 
>> code of 1 to indicate exit (whereas the patch makes an
> 
>> exit code of 2 now indicate exit). I notice also the
> 
>> patch makes the exit code of the Python version of
> 
>> gis_set.tcl be interpreted differently - has anybody
> 
>> checked what effect this will have?
> 
> 
>> The problem is the historical behaviour that an error in
> 
>> gis_set.tcl (e.g. the wrong version of Tcl/Tk) caused it
> 
>> to drop out from attempting the GUI startup but go ahead
> 
>> and start an interactive GRASS shell. When I made a few
> 
>> changes to the return codes from gis_set.tcl I
> 
>> deliberately avoided tackling this because I wasn't sure
> 
>> what was the best solution. But on thinking about it
> 
>> more, I think dropping to an interactive shell is the
> 
>> wrong approach. It should print a warning/error message
> 
>> and then exit, and if the user wants to start in
> 
>> text-based mode instead they can use the -text switch
> 
>> next time round.
> 
> 
>> init.bat assumes a return code of 1 means exit. I vaguely
> 
>> intended the same interpretation for Init.sh, and to
> 
>> remove the facility to drop to an interactive shell when
> 
>> there was an error in gis_set.tcl, but I didn't implement
> 
>> this nor tell anybody about my plans: my fault ;)
> 
> 
>> I think it would simplify things if we made Init.sh
> 
>> always exit when a non-zero exit code is returned from
> 
>> gis_set.tcl- any other thoughts? (I should probably
> 
>> update init.bat too so it goes ahead when 0 is returned, 
> 
>> rather than exiting when 1 is returned).
> 
> 
> 
> ----------------------------------------------------------------------
> 
> You can respond by visiting: 
> http://wald.intevation.org/tracker/?func=detail&atid=204&aid=478&group_id=21