Opened 11 years ago

Closed 10 years ago

#534 closed defect (fixed)

g.gui doesn't work in ms-windows

Reported by: cnielsen Owned by: grass-dev@…
Priority: major Milestone: 6.4.0
Component: wxGUI Version: svn-releasebranch64
Keywords: wingrass Cc: heshikik
CPU: Unspecified Platform: MSWindows XP

Description

From a self-compiled version (mingw/msys), or osgeo4w version, g.gui fails to restart the gui on windows. For the osgeo4w version I created a grass64 file and started from within an msys shell. No error messages appear in either case.

Fails to restart either the tcltk or wxpython gui

GRASS 6.4.0RC3 (Latlong):/d > g.gui wxpython
GRASS 6.4.0RC3 (Latlong):/d > 

Attachments (2)

g_gui_crash.jpg (40.6 KB) - added by neteler 10 years ago.
g.gui crashing in WinGRASS in Japanese Windows-XP
mswin_python_set.diff (2.2 KB) - added by hamish 10 years ago.
patch to set GRASS_PYTHON if it isn't already

Download all attachments as: .zip

Change History (19)

comment:1 Changed 10 years ago by cnielsen

Resolution: fixed
Status: newclosed

seems to be fixed

comment:2 Changed 10 years ago by neteler

Resolution: fixed
Status: closedreopened

comment:3 Changed 10 years ago by neteler

Version: unspecifiedsvn-releasebranch64

The problem persists on WindowsXP, Japanese version. See attachement.

Changed 10 years ago by neteler

Attachment: g_gui_crash.jpg added

g.gui crashing in WinGRASS in Japanese Windows-XP

comment:4 Changed 10 years ago by neteler

Component: defaultwxGUI

I tried with "tcltk" as parameter and it works. So the problem is "only" to launch "wxpython", in general g.gui.exe seems to be ok.

comment:5 in reply to:  4 ; Changed 10 years ago by glynn

Replying to neteler:

I tried with "tcltk" as parameter and it works. So the problem is "only" to launch "wxpython", in general g.gui.exe seems to be ok.

So the problem is with wxGUI, not g.gui? Does:

$GRASS_PYTHON $GISBASE/etc/wxpython/wxgui.py &

work?

comment:6 in reply to:  5 Changed 10 years ago by glynn

Replying to glynn:

Does:

$GRASS_PYTHON $GISBASE/etc/wxpython/wxgui.py &

work?

Duh; this is Windows; that should be:

"%GRASS_PYTHON%" "%WINGISBASE%\etc\wxpython\wxgui.py"

comment:7 Changed 10 years ago by neteler

Tested: the (simple) problem is that "%GRASS_PYTHON%" is not defined at all. When defining it manually (set GRASS_PYTHON=python), also g.gui works.

I see that the variable is defined in lib/init/init.sh but not in any .bat file.

comment:8 Changed 10 years ago by heshikik

Cc: heshikik added

comment:9 in reply to:  7 Changed 10 years ago by hamish

Replying to neteler:

I see that the variable is defined in lib/init/init.sh but not in any .bat file.

only by mswindows/osgeo4w/ini.bat.tmpl?

osgeo4w/ini.bat.tmpl:5:set GRASS_PYTHON=%OSGEO4W_ROOT%\bin\python.exe

Hamish

comment:10 Changed 10 years ago by hamish

testing on wingrass prev binary r40019-

from the "GRASS 6.4.SVN with MSYS" terminal prompt $GRASS_PYTHON is set (presumably by init.sh) and "g.gui wxpython" works.

from the "GRASS Command Line" menu item DOS-box %GRASS_PYTHON% is not set and "g.gui wxpython" fails unless I set it. It is best to fix init.bat of course, but perhaps we could also add a check to see if the getenv() in g.gui.c is empty, and if it is default to "python"?

Hamish

comment:11 in reply to:  10 Changed 10 years ago by neteler

Replying to hamish:

from the "GRASS Command Line" menu item DOS-box %GRASS_PYTHON% is not set and "g.gui wxpython" fails unless I set it. It is best to fix init.bat of course, but perhaps we could also add a check to see if the getenv() in g.gui.c is empty, and if it is default to "python"?

A default sounds good to me (just to "python") - if python is absent it would fail in any case.

Markus

Changed 10 years ago by hamish

Attachment: mswin_python_set.diff added

patch to set GRASS_PYTHON if it isn't already

comment:12 Changed 10 years ago by hamish

patch attached to this ticket vs. trunk to solve this in three different ways/places.

I'm a bit murky on the G_store() usage, so review before committing.

Hamish

comment:13 Changed 10 years ago by hamish

setting GRASS_PYTHON=python at the DOS prompt works.

I've committed to all branches the init.sh and grass.bat fixes from the patch. see svn r40435-7.

Putting a fail-safe in g.gui.c still needs to be decided but is not a blocker for release.

Hamish

comment:14 Changed 10 years ago by hamish

Keywords: wingrass added

comment:15 Changed 10 years ago by hamish

I'm a bit murky on the G_store() usage, so review.

svn diff trunk/general/g.gui/main.c
Index: main.c
===================================================================
--- main.c      (revision 40408)
+++ main.c      (working copy)
@@ -27,7 +27,7 @@
     struct Option *type, *rc_file;
     struct Flag *update, *nolaunch;
     struct GModule *module;
-    const char *gui_type_env;
+    const char *gui_type_env, *python_cmd;
     char progname[GPATH_MAX];
 
     G_gisinit(argv[0]);
@@ -103,14 +103,19 @@
 
     G_debug(1, "Attempting to start '%s' GUI ...", type->answer);
 
+    python_cmd = getenv("GRASS_PYTHON");
+
+    if(!python_cmd)
+       python_cmd = G_store("python");
+
     if (strcmp(type->answer, "wxpython") == 0) {
        sprintf(progname, "%s/etc/wxpython/wxgui.py", G_gisbase());
        if (rc_file->answer) {
-           G_spawn_ex(getenv("GRASS_PYTHON"), progname, progname,
+           G_spawn_ex(python_cmd, progname, progname,
                    "--workspace", rc_file->answer, SF_BACKGROUND, NULL);
        }
        else {
-           G_spawn_ex(getenv("GRASS_PYTHON"), progname, progname,
+           G_spawn_ex(python_cmd, progname, progname,
                    SF_BACKGROUND, NULL);
        }
     }

Hamish

comment:16 in reply to:  13 Changed 10 years ago by glynn

Replying to hamish:

Putting a fail-safe in g.gui.c still needs to be decided but is not a blocker for release.

It would also need to go into lib/gis/parser.c, g.mapsets/main.c, scripts/wxpyimgview/wxpyimgview.py, v.krige.py and d.rast.edit.py (when they eventually get fixed), and anything else which uses $GRASS_PYTHON.

IOW, it needs to be set in the startup scripts. Adding workarounds for specific cases is fixing the symptoms rather than the bug.

comment:17 Changed 10 years ago by hamish

Resolution: fixed
Status: reopenedclosed

ok, primary subject of bug is fixed on all platforms; adding multiple layers of redundancy to deal with missing GRASS_PYTHON and GRASS_WISH enviro variables will be a wontfix. we can reconsider that later if it ever becomes a real problem.

Hamish

Note: See TracTickets for help on using tickets.