Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#594 closed defect (wontfix)

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

Reported by: vince Owned by: grass-dev@…
Priority: major Milestone: 6.4.0
Component: wxGUI Version: 6.4.0 RCs
Keywords: wxGUI does not load Cc:
CPU: x86-64 Platform: MacOSX

Description

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

Change History (22)

comment:1 Changed 11 years ago by vince

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

comment:2 Changed 11 years ago 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.

comment:3 Changed 11 years ago by vince

Resolution: fixed
Status: newclosed

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.

comment:4 Changed 11 years ago by kyngchaos

Resolution: fixed
Status: closedreopened

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

comment:5 in reply to:  3 ; Changed 11 years ago by 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

comment:6 in reply to:  5 Changed 11 years ago by 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

comment:7 Changed 11 years ago by 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...

comment:8 Changed 10 years ago by 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

comment:9 Changed 10 years ago by 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.

comment:10 in reply to:  9 Changed 10 years ago by 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.

comment:11 Changed 10 years ago by 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.

comment:12 Changed 10 years ago by 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.

comment:13 Changed 10 years ago by 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.

comment:14 Changed 10 years ago by 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.

comment:15 Changed 10 years ago by cmbarton

Resolution: wontfix
Status: reopenedclosed

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

comment:16 in reply to:  15 ; Changed 10 years ago by 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

comment:17 in reply to:  16 Changed 10 years ago by 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.

comment:18 Changed 10 years ago by 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

comment:19 in reply to:  18 Changed 10 years ago by 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.

comment:20 Changed 10 years ago by 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.

comment:21 Changed 10 years ago by 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

comment:22 Changed 10 years ago by 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.

Note: See TracTickets for help on using tickets.