Opened 15 years ago

Closed 13 years ago

#532 closed defect (wontfix)

Vector editing not possible with wx tools

Reported by: geognu1 Owned by: grass-dev@…
Priority: major Milestone: 6.4.0
Component: wxGUI Version: 6.4.0 RCs
Keywords: vector, digit Cc: martinl
CPU: x86-32 Platform: All

Description

When you start editing a vector with wx interface you get in the command output:

Traceback (most recent call last): File "/home/user/releasebranch_6_4/dist.i686-pc-linux- gnu/etc/wxpython/gui_modules/wxgui_utils.py", line 512, in OnStartEditing

self.mapdisplay.toolbarsvdigit.StartEditing (maplayer) File "/home/user/releasebranch_6_4/dist.i686-pc-linux- gnu/etc/wxpython/gui_modules/toolbars.py", line 1099, in StartEditing

self.parent.digit = Digit(mapwindow=self.parent.MapWindow) File "/home/user/releasebranch_6_4/dist.i686-pc-linux- gnu/etc/wxpython/gui_modules/vdigit.py", line 685, in init

VDigit.init(self, mapwindow) File "/home/user/releasebranch_6_4/dist.i686-pc-linux- gnu/etc/wxpython/gui_modules/vdigit.py", line 223, in init

mapwindow) File "/home/user/releasebranch_6_4/dist.i686-pc-linux- gnu/etc/wxpython/vdigit/grass6_wxvdigit.py", line 327, in init

this = _grass6_wxvdigit.new_Digit(*args) TypeError : in method 'new_Digit', argument 2 of type 'wxWindow *'

The monitor gets erased and editing it is not possible

Change History (24)

comment:1 by martinl, 15 years ago

Which version of swig do you use?

in reply to:  1 comment:2 by geognu1, 15 years ago

Replying to martinl:

Which version of swig do you use?

SWIG Version 1.3.38 Compiled with g++ [i686-pc-linux-gnu]

comment:3 by neteler, 15 years ago

Here a recent note from grass-user (copied here for reference):

On Mon, Mar 16, 2009 at 6:13 AM, Huidae Cho wrote:

After investing some time, I found a note in swig-1.3.38/Tools/pyname_patch.py saying that they have renamed PySwig* to SwigPy* since swig 1.3.37. wxPython 2.8.9.2 (current stable version) still uses old naming, so we have to stick to swig >= 1.3.31 and <= 1.3.36. Now, GUI works great!

in reply to:  3 ; comment:4 by geognu, 15 years ago

No way. Downgraded swig to v. 1.3.36, still get the same message.

comment:5 by cmbarton, 15 years ago

Platform: LinuxAll

I cannot do any digitizing on 6.4 on the Mac OSX platform. As soon as I try to select a map to digitize in the pull down, the GUI crashes. This happens if I try to select an existing map or create a new map.

Digitizing works with 6.5 on my Mac.

This remains a serious issue for a 6.4 release.

Michael

comment:6 by kyngchaos, 15 years ago

I just tried with 6.4svn (from earlier in the week) built with Snow's Python 2.6.1 and my own wxpython 2.8.10.1 and digitizing works. I'm sure it worked for me on OSX 10.5 with 6.4rc5, the system python 2.5 and wx 2.8.10.1.

comment:7 by cmbarton, 15 years ago

This works fine for me now on the Mac. I have swig 1.3.31.

My problem was probably due to a second Python installation that was not completely removed. This caused problems during compiling that affected the digitizing module, especially the one creating the local PsuedoDC. It is not a problem if the wxpython used to compile is bundled with the app on the Mac. For other reasons, we will need to do this regularly if we want digitizing to work with portable binaries.

Is this a problem on other systems with swig 1.3.31?

Michael

comment:8 by cmbarton, 15 years ago

Can we close???

Michael

in reply to:  8 comment:9 by martinl, 15 years ago

Cc: martinl added

Replying to cmbarton:

Can we close???

I don't think so. The problem still remains in different forms, but usually it's cause by incompatible version of swig and wxPython.

Martin

comment:10 by cmbarton, 15 years ago

Then isn't this really something that needs to be fixed in compiling? I don't think this is really a wxGUI issue is it?

Michael

in reply to:  4 ; comment:11 by hamish, 14 years ago

Replying to geognu:

No way. Downgraded swig to v. 1.3.36, still get the same message.

still seeing it with the latest svn? what linux distro/version are you using?

Hamish

comment:12 by geognu, 14 years ago

Didn't try the latest svn, but AFAIK problems still arise with wx interface on grass 6.4.0rc5 (shipped with Ubuntu Karmic): grass -wx Cleaning up temporary files ... Starting GRASS ... Traceback (most recent call last):

File "/usr/lib/grass64/etc/wxpython/gis_set.py", line 33, in <module>

from gui_modules import globalvar

File "/usr/lib/grass64/etc/wxpython/gui_modules/globalvar.py", line 55, in <module>

CheckForWx()

File "/usr/lib/grass64/etc/wxpython/gui_modules/globalvar.py", line 44, in CheckForWx

except (ImportError, ValueError, wxversion.VersionError), e:

UnboundLocalError: local variable 'wxversion' referenced before assignment Error in GUI startup. If necessary, please report this error to the GRASS developers. Switching to text mode now.

comment:13 by hamish, 14 years ago

6.4.0rc5 is like 6 months old now, hundreds of fixes since then, especially to the wx gui. hopefully we will see a rc6 soon. (debian/unstable has packages with modern 6.4.SVN snapshots btw)

Hamish

in reply to:  11 ; comment:14 by neteler, 14 years ago

Replying to hamish:

Replying to geognu:

No way. Downgraded swig to v. 1.3.36, still get the same message.

still seeing it with the latest svn? what linux distro/version are you using?

Also for me it fails *since* RC5. Despite a locally downgraded swig to v. 1.3.36, no way to get the GUI up if wx-nviz and wx-vdigit are present. A real showstopper to showcase the new GUI...

I have no clue how to debug this issue.

Markus

in reply to:  14 ; comment:15 by glynn, 14 years ago

Replying to neteler:

Also for me it fails *since* RC5.

With a "'wxversion' referenced before assignment" error?

There has been an attempt at fixing that, but I'm still not sure that it's correct. I think that CheckForWx() should look like:

try:
    import wxversion
    try:
        wxversion.select(...)
        import wx
        # the rest of CheckForWx() goes here
        ....
    except wxversion.VersionError, e:
        ...
except ImportError, e:
    ...

Any references to wxversion should only appear in the same scope as the "import wxversion", not in any outer scope.

Despite a locally downgraded swig to v. 1.3.36, no way to get the GUI up if wx-nviz and wx-vdigit are present. A real showstopper to showcase the new GUI...

For release candidates and any eventual release, I strongly suggest building --without-wxwidgets. It's not worth the risk of losing the whole wxGUI over those two modules.

in reply to:  15 ; comment:16 by neteler, 14 years ago

Replying to glynn:

Replying to neteler:

Also for me it fails *since* RC5.

With a "'wxversion' referenced before assignment" error?

It fails silently. Also when using 'g.gui wxpython': the old map flashed, then return to command line and nothing else.

comment:17 by cmbarton, 14 years ago

Markus,

We had identical symptoms on Linux machines. The cause for use was not in wxpython but in GDAL. If the GUI cannot get projection information, it cannot start. Isaac corresponded with you about this. There has been a problem with GRASS recognizing a linked *.so file (I can't remember which one, but you might find it in your back email.)

Michael

in reply to:  16 comment:18 by hamish, 14 years ago

Replying to neteler:

Also when using 'g.gui wxpython': the old map flashed, then return to command line and nothing else.

hmm, I just saw that myself on startup.

I ran g.gui at the terminal prompt and it worked fine from there.

?, Hamish

comment:19 by cmbarton, 14 years ago

There are 2 possibly related or possibly unrelated errors going on here.

1) GUI just doesn't start 2) GUI attempts to start (flashes on screen) but fails and quits

To get started on debugging this, can someone tell me where exactly is the code that launches the GUI?

Michael

in reply to:  14 comment:20 by hamish, 14 years ago

Replying to neteler:

Also for me it fails *since* RC5. Despite a locally downgraded swig to v. 1.3.36,

...

I have no clue how to debug this issue.

brute force approach- svn checkout by date, starting at the first of each month since RC5, build, check, repeat. when you find the month the change happened in, checkout from the 15th of that month. & again to find the week. Once you know the week search the trac changelog for anything that looks suspicious. Probably would take about 6 builds to narrow it down to the week of the change.

Replying to Michael:

To get started on debugging this, can someone tell me where exactly is the code that launches the GUI?

init.sh calls

$GISBASE/etc/wxpython/gis_set.py

g.gui calls:

python $GISBASE/etc/wxpython/wxgui.py

Hamish

comment:21 by cmbarton, 14 years ago

I think I found where the problem lies, though I don't understand why it is a problem. On 13 February, r40985 fixed 2 typos--one in init.sh and another in function.sh. William mentioned these but they didn't seem to make any difference. However, I was able to stop the opening screen enough to catch the following:

/Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/functions.sh: line 599: /Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/wxpython/wxgui: No such file or directory

Since wxgui.py is what is launching GRASS, I suspect that the immediate cause is fixing the typo in functions.sh, maybe in combination with fixing the typo in init.sh.

Michael

in reply to:  16 comment:22 by neteler, 14 years ago

Replying to neteler:

Replying to glynn:

Replying to neteler:

Also for me it fails *since* RC5.

With a "'wxversion' referenced before assignment" error?

It fails silently. Also when using 'g.gui wxpython': the old map flashed, then return to command line and nothing else.

This problem has been solved: it was "wxPythonGTK" being compiled with internal expat support instead of --with-expat=sys. To verify:

ldd /usr/lib/wxPython/lib/libwx_gtk2u-2.8.so.0.5.0 | grep expat
-> no link to external libexpat as it should be

Recompilation of wxPythonGTK with --with-expat=sys solved this problem, wxGUI is now functional.

comment:23 by cmbarton, 14 years ago

Can this now be closed??

Michael

in reply to:  23 comment:24 by martinl, 13 years ago

Resolution: wontfix
Status: newclosed

Replying to cmbarton:

Can this now be closed??

yes, digitizer is not using swig anymore. It was backported to python/ctypes.

Note: See TracTickets for help on using tickets.