#594: wx GUI won't start (Mac OS X 10.5.6) / Python 2.6 / wxWidgets 2.8.10 /
wxWidget 2.8.9.2
---------------------------------+------------------------------------------
Reporter: vince | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Keywords: wxGUI does not load | Platform: MacOSX
Cpu: x86-64 |
---------------------------------+------------------------------------------
There are several issues at stake when building Grass on MacOS, especially
when the scope is to generated a universal build.
1. wxwidgets and so Wxpython are not universal, but 32-bit only (wxwidgets
depends on Carbon and Quicktime APIs, which are 32-bit only. This is going
to change anytime soon, but it is not yet done). A configure option should
be added to purposely choose the correct version of python (mixing 64-bit
Python with 32-bit wxpython results in a clash).
2. The GUI does not work. I get this message:
{{{
-> grass64 -wx
Cleaning up temporary files ...
Starting GRASS ...
This program needs access to the screen.
Please run with 'pythonw', not 'python', and only when you are logged
in on the main display of your Mac.
Error in GUI startup. If necessary, please
report this error to the GRASS developers.
Switching to text mode now.
Hit RETURN to continue...
}}}
I specify that I use the macports environnement (I'm porting Grass 6.4 to
it).
#594: wx GUI won't start (Mac OS X 10.5.6) / Python 2.6 / wxWidgets 2.8.10 /
wxPyhton 2.8.9.2
---------------------+------------------------------------------------------
Reporter: vince | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wxGUI does not load
Platform: MacOSX | Cpu: x86-64
---------------------+------------------------------------------------------
Comment (by kyngchaos):
> 1. wxwidgets and so Wxpython are not universal, but 32-bit only
I had a line in the makefile that would strip out 64bit arch flags for
OSX, but this was lost in the switch to the setup.py method of
compilation. Something similar must be done in setup.py, but I haven't
had time yet to tinker with it. Martin may be able to do something.
Note: this is only specific to wx nviz and vdigit, which have binary-
compiled components. The rest of the GUI should work, if it wasn't for
item 2.
Ok, I have a fix.
In g.gui main.c, the "python" string should be replaced by the full path
leading to pythonw-32.
Next, the Python function reexec_with_pythonw should be emptied, and
replaced by a pass.
It then works.
I am going to put all this in the Portfile I'm preparing.
Um, fixing it externally doesn't help the GRASS source. I'm reopening
this because these are still valid issues for those of us who don't use
macports (or fink).
Replying to [comment:3 vince]:
> Ok, I have a fix.
> In g.gui main.c, the "python" string should be replaced by the
> full path leading to pythonw-32.
> Next, the Python function reexec_with_pythonw should be
> emptied, and replaced by a pass.
> It then works.
ok, so for g.gui it should use G_getenv("GRASS_PYTHON") instead of
hardcoding "python", just like it does for GRASS_WISH.
{{{
- G_spawn("python", "wxgui", progname, NULL);
+ G_spawn(G_getenv("GRASS_PYTHON"), "wxgui", progname, NULL);
}}}
shouldn't GRASS_WISH use G_getenv() there instead of getenv() directly?
Besides, I can't figure out how the python routine reexec_with_pythonw is
supposed to work. On my machine, the __file__ variable used to design the
file to be reexec'ed expands to utils.py, so the file being reexec'ed is
the file containing the routine, which does nothing (since this file
contains only def's and no main code).
Other question: if I understand correctly the behaviour of Grass, all
fonctions called from the GUI are exec'ed via fork ()/G_spawn () (unlike
Qgis)? That's to decide if it makes sense to have a 32-bit GUI and 64-bit
functions...
I'm pretty sure that this is now fixed. No problem now with Mac starting
as described. But there may be a related problem. The wxPython GUI only
seems to start now if the user has <b>exactly</b> the same version that it
was compiled with.
It should run with all versions of wxPython above 2.8.0, but if I compile
with 2.8.9.2, it only runs with 2.8.9.2. Otherwise it generates a bad
version error.
Is this a different issue (needing its own ticket) or another
manifestation of the issue described here?
I'll try, but in the meanwhile I have moved to Snow Leopard, and wxwidgets
on SL is at best a maze (SL default to 64bit, whereas 10.5 was 32bit).
First, I must try wxWidgets 2.9.0 with the cocoa option, and see what is
going on. This has nothing to do with Grass, but I can't do a thing
without those preliminary steps.
The way wxPYthon is built (official binaries), the wx libraries are
hardwired to individual versioned folders. I guess for pure python code
(the GUI in general) this wouldn't matter, but for nviz and vdigit it
does.
Replying to [comment:9 vince]:
wx cocoa is unfinished, so it may not be usable yet for the GUI. Note
that there is new code in the startup for the OSX app that works around
the 64bit python issue. If you don't set GRASS_PYTHON, it should find a
usable python of the correct version and architecture.
Ok, good news, I have a universal 32/64-build build for wxWidgets and
wxPython based on the new wxcocoa. I'll proceed and see how it does show
up in Grass.
Good. I have a 32/64 universal build. There are some issues in the vdigit
modules, I had to patch pseudodc.cpp and pseudodc.h in order to compile
it. The rest is okay, very nice the way configure gracefully handles
multiple archs.
Besides, in wxpython/gui_modules/globalvar.py, I had to comment out this
line:
{{{
wxversion.select(str(minVersion[0]) + '.' + str(minVersion[1]))
}}}
because otherwise it would not launch the GUI (the version reported by my
WxPython is 2.9.0.0). Now I'll test it a bit more carefully.
Well, there are some bugs (e.g. I can't open a file with the file
selector, so I cannot import anything), but I am, of course, unable to
tell if this is caused by Grass, by Wxpython or (most probably) by
wxwidgets-cocoa. Stay tuned.
Note that we've found that vdigit works when wxpython in bundled in the
app package, for some reason (possibly wxpython version confusion). I
don't know if this will help the GUI in general.
1) have the same version of wxPython installed that GRASS was compile
with, or
2) bundle wxPython with the binary.
Option #2 is the only way to make a binary portable on a Mac, but it is
easy to do with the files that William Kyngesburye has put in the source
tree.
He has also solved compiling GRASS for Snow Leopard.
Using Python 2.6 is a completely different issue and could take some
considerable rewriting of the GUI.
I'm closing this with a "wontfix" because it is fixed as much as it can
be, and we can now produce portable binaries for Leopard and Snow Leopard
on the Mac.
Replying to [comment:16 glynn]:
> Replying to [comment:15 cmbarton]:
>
> > Using Python 2.6 is a completely different issue and could take some
considerable rewriting of the GUI.
>
> How so? While 2.6 adds many new features, very little existing
functionality has been removed or changed.
>
> http://docs.python.org/whatsnew/2.6.html#porting-to-python-2-6
Probably Michael is referring to Python 3.x not 2.6 (?). Python 2.6 should
be OK for the current wxGUI.
No. Actually I was talking about 2.6. From what I've read, 3.0 is not
backward compatible and would take serious rewriting. Also, there is no
wxPython for 3.0.
However, from talking with colleagues who program a lot in Python, 2.6 is
supposedly different in a sufficient number of respects to run a risk of
breaking many programs in some way or another. There are migration
utilities to make this easier. In our case we would not know how much
would need to be changed until we run it and see what breaks. Maybe
little, if we are lucky. But it's not a matter of just porting with no
changes--as was the case from 2.4 to 2.5 for us.
> However, from talking with colleagues who program a lot in Python, 2.6
is supposedly different in a sufficient number of respects to run a risk
of breaking many programs in some way or another.
[citation needed]
The whole point of 2.6 is to provide access to as many 3.0 features as
possible '''without''' breaking compatibility with previous 2.x versions.
> There are migration utilities to make this easier.
I can't find any mention of this. The only migration utility I know of is
"2to3", for converting 2.x code to 3.0.