wingrass: launching gui and shell [was: Re: [GRASS-dev] Wingrass and TclTk]

[Moritz Lennert]

Hello Paul,

On Thu, November 1, 2007 22:28, Paul Kelly wrote:
> I'm trying to follow what's going on here but it's  bit confusing -
would
> help if somebody posted a diff of the proposed changes to init.bat (the
usual way).

Yes, sorry. Here it is:

--- grasssrc/grass6/lib/init/init.bat   Thu Nov  1 22:32:29 2007
+++ init.bat.new        Thu Nov  1 22:56:41 2007
@@ -95,13 +95,17 @@
 rem This doesn't seem to work; don't understand return codes from
gis_set.tcl P                                             K
 rem if return ok, gis.m start:
 if %errorlevel% == 2 goto exitinit
-
-if not "%GRASS_WISH%"=="" (
-  "%GRASS_WISH%" "%WINGISBASE%\etc\gm\gm.tcl"
-) else (
-  "%WINGISBASE%\etc\gm\gm.tcl"
-)
-
+
+rem Get LOCATION_NAME to use in prompt
+FOR /F "usebackq delims==" %%i IN (`g.gisenv "get=LOCATION_NAME"`) DO @set
+LOCATION_NAME=%%i
+
+cd %HOME%
+prompt GRASS %GRASS_VERSION% $C%LOCATION_NAME%$F:$P $G
+start "GRASS %GRASS_VERSION% Shell" cmd.exe
+
+%WINGISBASE%\bin\gis.m.bat
+
 "%WINGISBASE%\etc\clean_temp" > NUL:

 goto exitinit



> Have a few comments anyway about my original philosophy of why
> init.bat does things the way it does, which hopefully might help clarify
things.
> There is not supposed to be a command-prompt running separately from
that
> included in gis.m - I thought we were moving towards the idea of having
a
> command prompt built into the gronsole Window and using that (I think
it's
> improved further in wxgrass) - so that was the point of that.

Well, currently the gronsole command prompt is very limited, and so having
access to a console still has its advantages. Current feedback from
wingrass users shows that there are not only windows users afraid of
anything which remotely looks like a command prompt, but also those users
who are comfortable with grass on the command line in *nix and would like
to (or have to) run grass on a windows machine. From Benjamin's
suggestions I also had the feeling that there is a need for the console...

But if we decide to leave the console for power users who can find out how
to start grass in text mode and, if needed, launch gis.m from there, I'm
fine with that as well. A new gis.m.bat as the one I proposed makes this
easier.

> I think it
> is confusing for new users having to type exit in a command Window to
totally exit GRASS as well as just going File-->Exit in the GUI menus
(is
> that what's being proposed here?).

It is. This is how it has been for users on other platforms for quite a
while. Yes it is a bit confusing, but if we think that having a console is
important it might be the lesser of evils.

> If somebody wants a GUI and console then I think it's OK to require them
to start GRASS in text mode and run gis.m from the command prompt. So I
actually think Moritz's new gis.m.bat is a really good idea.

+1
Benjamin ?

> And there was some
> complication about the way the gis.m Shell script was generated although
I
> think I simplified things a little bit.

Currently the gis.m.bat script is created via Script.Make, just as any
other script. But it shouldn't as it is a special case where the script
does not need sh.exe to be launched. This is why I'm looking for a way to
treat gis.m differently from the other scripts.

> Also I'm not sure what the "cd %HOME%" is for. GRASS on Unix doesn't
change the directory you were in before starting it AFAIK - why should
it
> on Windows?

Because you don't start it from a command line, but by clicking on the
grass63.bat file, and so it always starts in c:\grass\bin or wherever the
.bat file resides. You can obviously change this behaviour when you make a
shortcut which you put on your desktop and in the properties of which you
can set a startup directory, but once again we're already at the level of
a more advanced user here. To me starting in the %HOME% directory seems
the most intuitive in a windows environment.

> And how important is the "/E:ON /F:ON /V:ON"?

For the record
(http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/cmd.mspx?mfr=true):
/e:on : Enables command extensions. [but only for a limited list of
commands]
/f:on : Enables file and directory name completion.
/v:on : Enables delayed environment variable expansion.

Probably not important at all and they can always be set by the user if
they want to.  Actually in XP /E is set on by default AFAICT.

> I just want to
> be sure we're not introducing anything that doesn't *need* to be there
and
> is only likely to confuse people in years to come.

>> where gis.m.bat simply contains:
>> ===
>> @ start "GIS Manager" "%GRASS_WISH%" "%WINGISBASE%/etc/gm/gm.tcl" ===
>> This way we have a functioning gis.m.bat which one can also launch from
the command line if grass was started with in text mode.
>
> That's a good idea. ISTR that the gis.m shell script now also runs gis.m
in the background, i.e. you don't need to run it as "gis.m &" any more -
is that right?

This is because in the gis.m script launches gm.tcl with the ampersand:

exec "$GRASS_WISH" "$GISBASE/etc/gm/gm.tcl" -name gm_tcl &

IIUC, this will not work in windows, however, and so we use the windows
specific 'start' command.

>
> We'd need to make sure GRASS_WISH is always set though. Currently
init.bat
> doesn't require it to be set and will use Window's association of .tcl
files with the Tcl interpreter to start gis.m correctly if not.

Are you sure ? In init.bat, we currently have:

if "%GRASS_WISH%"=="" set GRASS_WISH=wish.exe

So unless someone explicitely unset GRASS_WISH, it will always be set.
I've actually tried running gis.m with GRASS_WISH unset and it starts but
crashes immediately because of the missing GRASS_WISH. This is probably
due to:

/c/grass/grass-6.3.cvs/etc/gm$ grep WISH *
animate.tcl:# exec $GRASS_WISH "$0" "$@"
gmmenu.tcl:     {command {[G_msg "About &System"]} {} {[G_msg "About
System"]} {} -command { exec $env(GRASS_WISH)
$env(GISBASE)/etc/gm/tksys.tcl --tcltk & }}
tksys.tcl:exec $GRASS_WISH "$0" "$@"



> But I
> don't think it's unreasonable to require GRASS_WISH to always be set and
we could change that.
>> Nice also to finally get rid of this empty and useless cmd.exe window
we
>> had before.
>
> Do you mean with the changes the init.bat script is exiting/abandoning
after starting gis.m? The whole point of it staying running (and as a
side-effect keeping a command prompt Window open - I don't know how to
hide that but I presume it's possible) is because there are actions that
run as part of exiting GRASS - the main one being deleting temporary
files, but also setting the PATH back to its original value if a
command-line session was being run. If we exit init.bat after starting
gis.m then the temporary files won't be deleted on exit which I don't
think is a good idea.

Yes. I had forgotten about all that. So, we'll have to find another way.

Just as a reminder: the problem is that windows automatically opens a
cmd.exe window when you launch a .bat file. I think that unless you use
some other programming language that calls this .bat file (instead of just
clicking on it), this is unavoidable. But it is not so nice to have this
"useless" cmd.exe window open all the time.

Actually you can hide the window if you use a shortcut to grass63.bat. In
its properties you can set it to "minimized". But again, this means more
advanced user action than what we seem to aim at.
We could maybe include a .lnk file in the distribution for which this is
preset. Don't know how portable these binary .lnk files are...

One option would be to use the start command in grass63.bat, such as:

start /min cmd /c "%WINGISBASE%\etc\init.bat" %*

It spawns a new minimized cmd.exe which then runs init.bat. This works
great for GUI startup, but when you launch grass63.bat -text, you have the
incovenience of a) another cmd window open for grass and b) you have to
maximize the window to be able to enter grass. And since the 'text' option
can come from the .grassrc6 file, we cannot count on a '-text' parameter
being available in grass63.bat.

We could have another .bat file which contains the call to gm.tcl and the
exit clean up routines and call this .bat file with start /min from
Init.bat. However, if you give it a .bat file, start will keep the cmd
window open even after the script finishes. This means you have to then
maximize the window and close it yourself...

So, currently, the only satisfying options I see is to either teach people
how to make a shortcut to their desktop (or wherever they want) and to
configure this shortcut to minimize the cmd.exe window, or to create some
sort of executable (in tcl, python or whatever) that calls grass63.bat.

But maybe someone else has a better idea...

>> Only thing which is a bit annoying: you have to close the two (cmd and
gis.m) seperately (i.e. gis.m does not close when you type exit in
cmd.exe). But that's minor in my eyes.
>
> Users who don't normally use the command line may not know to type exit

True.

> I think it's a big enough issue not to introduce it as a problem when it
> wasn't there before - see my comments above.

Ok, won't for now, then.

>> One question I don't know how to solve, though: just as for other scripts
>> a gis.m.bat is created during compilation, which contains:
>> @"%GRASS_SH%" -c '"%GISBASE%/scripts/gis.m" %*'
>> However, I think that gis.m should run independently of whether someone
has installed a shell, so I'd rather replace this bat file by the one
above. This would mean creating some form of exception for gis.m to the
below entry in include/Make/Script.make:
>
> It was my idea for a while (never implemented it though) that the Script
Makefile could look and see if there was a "Windows version" (i.e. the
script name with a .bat extension) in the same directory, and if so
install it rather than installing a wrapper to the Bourne shell version
of
> the script. Would that perhaps be useful here if we got it working?

Yes, definitely. Do I understand correctly that this would mean that
instead of running

$(BIN)/$(PGM).bat: $(MODULE_TOPDIR)/scripts/windows_launch.bat^M
        sed -e "s#SCRIPT_NAME#$(PGM)#"
$(MODULE_TOPDIR)/scripts/windows_launch.bat > $@

on every script, we only run it for those scripts which do not have an
equivalent .bat in the scripts directory ? Currently this would only
concern gis.m, but if someone writes a cmd.exe replacement of another
script, this would also be included.


> but have a regular connection again so should hopefully be able to
> contribute a bit more now.

Great to have you back !

Moritz