WinGrass64 - windows-commandline not released

[hellik]

thinking about ticket #1092 (​http://trac.osgeo.org/grass/ticket/1092) and an improved WinGrass - R integration in the Windows-world, there is following issue with WinGrass64:

by clicking on the desktop-shortcut "GRASS 6.4.SVN" (nightly build), there is a windwows-command- line started in the background of the wx-gui.

(see ​http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/mswindows/GRASS-Installer.nsi#L573)

but the windows-command-line isn't released, so there's no access to the command-line.

in WinGrass7 (nightly build) the windows-commandline is released and with ticket #1092 you can start R within a WinGrass7-session in the windows-command-line.

so any hints for improving this situation for WinGrass64?

best regards Helmut

[hellik]

Replying to hellik:

so any hints for improving this situation for WinGrass64?

maybe any ideas for following situation?

• starting "WinGRASS6.4.1 Command Line"
• do g.gui wxpython
• the wxgui is starting, but it's not possible to type anything in the windows command line because it's locked as long the wxgui is opened

any hints what to do that the windows command line isn't locked as long the wxgui is opened?

Helmut

[smitch]

Just found this bug report while searching for hints on the same problem in our GIS lab. In our case, GRASS was installed using OSGEO4W, but the symptoms are the same. If the wxpython GUI is selected as the current interface, the command prompt is not interactive.

Workaround we're using for now: students are told to launch the OSGEO4W shell, then from within that use grass64 -gui to fire up the old TclTk GUI so they can choose their mapset etc., then quit the gui, then in the shell, enter g.gui gui=wxpython& so that wxpython goes into the background as it should.

I have not had time to look at the grass64 batch file to compare how wxpython is fired up compared to the tcltk version, but clearly the old way is "correct" at least in terms of user experience.

[neteler]

See also ticket #1891

[hamish]

idea: have the startup .bat file (grass643svn.bat) as its last command call "g.gui -wx", which should launch the GUI and safely background it in C with G_spawn_ex(). I'm not sure if the .bat would then exit or go to the GRASS> prompt, if exit maybe have it run bash.exe or cmd.exe to keep the session alive?

Hamish

[hellik]

Replying to hellik:

Replying to hellik:

so any hints for improving this situation for WinGrass64?

maybe any ideas for following situation?

• starting "WinGRASS6.4.1 Command Line"
• do g.gui wxpython
• the wxgui is starting, but it's not possible to type anything in the windows command line because it's locked as long the wxgui is opened

any hints what to do that the windows command line isn't locked as long the wxgui is opened?

Helmut

fixed in new stable release; closing ticket.