wx GUI won't start (Mac OS X 10.5.6) / Python 2.6 / wxWidgets 2.8.10 / wxPyhton 2.8.9.2

[vince]

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).

[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.

[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.

I am going to put all this in the Portfile I'm preparing.

V.

[kyngchaos]

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).

[hamish]

Replying to 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?

Hamish

[hamish]

Replying to hamish:

shouldn't GRASS_WISH use G_getenv() there instead of getenv() directly?

sorry, those should all be plain getenv(). G_getenv() is for g.gisenv gis variables.

Hamish

[vince]

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...

[cmbarton]

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?

Michael

[vince]

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.

[kyngchaos]

Replying to cmbarton:

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 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.

[vince]

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.

[vince]

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.

[vince]

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.

[kyngchaos]

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.

* http://grass.osgeo.org/wiki/Packaging_on_MacOSX#wxPython

[cmbarton]

AFAICT, to run Mac binaries with vdigit, we must:

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.

Michael

[glynn]

Replying to 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

[martinl]

Replying to glynn:

Replying to 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.

[cmbarton]

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.

Michael

[glynn]

Replying to cmbarton:

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.

[vince]

As far as I know, I agree with the latest comment. One of the major point in using 2.6 rather than 2.5 is its solid 64-bit support (at least on Mac OS), whereas 2.5 is practically only usable in 32-bit. With python 2.6 and wxwidgets 64-bits built on Cocoa, I can get a 64-bit wxpython and thus a full 64-bit build of Grass. It is only experimental, though: I can't do a thing with it (it is not even possible to open a single file, the file selector code seems to be broken). I could not do that with Python 2.5. It will take a while for wxcocoa to evolve into a fully mature version but, at least, the possibility of a full, modern 64-bit app is demonstrated.

[cmbarton]

Don't get me wrong. I'm in favor of moving in that direction. However, I just think that it is wise to complete the GUI with the version of Python we started with before porting to a new one. It's especially important to get 6.4 out the door as a stable version with as many bugs fixed as possible. Then we can move on to GRASS 7 development. The other issue of writing for Python 2.6 is that we need to make sure that the majority of Mac, Windows, and Linux distros will be able to run the GUI. Mac just moved to 2.6 (with the majority of users still at 2.5) and I'm not sure where the other platforms are at currently.

Michael

[vince]

I see no reason why wxpython on 2.6 should behave any differently that wxpython on 2.5. My concern is more with the cocoa 64-bit port, but, at this stage, I think that all the bugs I'm seeing are not caused by Grass, but rather by wxcocoa being at an alpha stage and thus yet buggy. However, I cannot be 100 % affirmative.