Opened 14 years ago

Closed 9 years ago

#1103 closed enhancement (fixed)

WinGrass64 - windows-commandline not released

Reported by: hellik Owned by: grass-dev@…
Priority: normal Milestone: 6.4.4
Component: Packaging Version: svn-releasebranch64
Keywords: wingrass, Cc: smitch
CPU: All Platform: MSWindows Vista

Description

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

Change History (7)

comment:1 by hellik, 14 years ago

Milestone: 6.4.16.4.2

in reply to:  description ; comment:2 by hellik, 14 years ago

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

comment:3 by smitch, 12 years ago

Cc: smitch added

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.

comment:4 by hellik, 12 years ago

Milestone: 6.4.26.4.4

comment:5 by neteler, 12 years ago

See also ticket #1891

comment:6 by hamish, 12 years ago

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

in reply to:  2 comment:7 by hellik, 9 years ago

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.