I'm trying to build wxQtMovie to work with the latest wxPython preview release, but when I try and build qtmovie_wrap.cpp, I get a bunch of errors like so:
wxQtMovie.h: In function `PyObject* _wrap_new_wxQtMovie(PyObject*, PyObject*,
PyObject*)':
wxQtMovie.h:57: error: `wxQtMovie::wxQtMovie(wxWindow*, int, const wxString&,
const wxPoint& = wxDefaultPosition, const wxSize& = wxDefaultSize, long int
= 0, const wxString& = wxQtMovieNameStr)' is protected
mac/qtmovie_wrap.cpp:530: error: within this context
wxQtMovie.h: In function `PyObject* _wrap_wxQtMovie_Create(PyObject*,
PyObject*, PyObject*)':
This error appears for every method in the class. The methods of course aren't protected, and building this same source worked with 2.5.2.7, so I'm guessing something's changed with the SWIG wrapping process. I looked at webkit.i and saw some changes, but I'm not sure if any of them affect this situation (and so far, no luck copying and pasting bits from one to the other). Any ideas?
I'm trying to build wxQtMovie to work with the latest wxPython preview release, but when I try and build qtmovie_wrap.cpp, I get a bunch of errors like so:
wxQtMovie.h: In function `PyObject* _wrap_new_wxQtMovie(PyObject*, PyObject*,
PyObject*)':
wxQtMovie.h:57: error: `wxQtMovie::wxQtMovie(wxWindow*, int, const wxString&,
const wxPoint& = wxDefaultPosition, const wxSize& = wxDefaultSize, long int
= 0, const wxString& = wxQtMovieNameStr)' is protected
mac/qtmovie_wrap.cpp:530: error: within this context
wxQtMovie.h: In function `PyObject* _wrap_wxQtMovie_Create(PyObject*,
PyObject*, PyObject*)':
This error appears for every method in the class. The methods of course aren't protected, and building this same source worked with 2.5.2.7, so I'm guessing something's changed with the SWIG wrapping process. I looked at webkit.i and saw some changes, but I'm not sure if any of them affect this situation (and so far, no luck copying and pasting bits from one to the other). Any ideas?
None. Let me see your current .h and .i files.
There have been some SWIG related changes since 2.5.2.7, but they shouldn't have any affect like this. I upgraded to the 1.3.22 release version of swig (plus my patch) instead of needing a specific CVS snapshot. That affected what the generated code looks like, but I only had to make minimal changes to my existing .i files (if any) when I made the change. The changes I made to webkit.i woudl have been needed before the swig update as well.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Hi,
I'm trying to build wxQtMovie to work with the latest wxPython preview release, but when I try and build qtmovie_wrap.cpp, I get a bunch of errors like so:
wxQtMovie.h: In function `PyObject* _wrap_new_wxQtMovie(PyObject*, PyObject*,
PyObject*)':
wxQtMovie.h:57: error: `wxQtMovie::wxQtMovie(wxWindow*, int, const wxString&,
const wxPoint& = wxDefaultPosition, const wxSize& = wxDefaultSize, long int
= 0, const wxString& = wxQtMovieNameStr)' is protected
mac/qtmovie_wrap.cpp:530: error: within this context
wxQtMovie.h: In function `PyObject* _wrap_wxQtMovie_Create(PyObject*,
PyObject*, PyObject*)':
This error appears for every method in the class. The methods of course aren't protected, and building this same source worked with 2.5.2.7, so I'm guessing something's changed with the SWIG wrapping process. I looked at webkit.i and saw some changes, but I'm not sure if any of them affect this situation (and so far, no luck copying and pasting bits from one to the other). Any ideas?
None. Let me see your current .h and .i files.
There have been some SWIG related changes since 2.5.2.7, but they shouldn't have any affect like this. I upgraded to the 1.3.22 release version of swig (plus my patch) instead of needing a specific CVS snapshot. That affected what the generated code looks like, but I only had to make minimal changes to my existing .i files (if any) when I made the change. The changes I made to webkit.i woudl have been needed before the swig update as well.
Well, having exhausted the possibility that it may have been a change in the .i files, I went back to the drawing board and revisited the header file, checking it with other classes. After fooling around a bit, I found out it was because I had the DECLARE_EVENT_TABLE() macro in the "public:" section of the header. Moving it to protected resolved the issue. But I'm quite sure that this did work before, as I remember testing with sizing and paint events installed. Should this work, or was I obviously doing something wrong (and somehow got away with it =)?
Oh, one other thing. Right now the extension module installation process doesn't work quite right, because the site-packages modules are now versioned and setup.py wants to install to "wx" and "wxPython". Maybe on *nix we could have wx and wxPython sym-links that point to the correct folders?
Well, having exhausted the possibility that it may have been a change in the .i files, I went back to the drawing board and revisited the header file, checking it with other classes. After fooling around a bit, I found out it was because I had the DECLARE_EVENT_TABLE() macro in the "public:" section of the header. Moving it to protected resolved the issue. But I'm quite sure that this did work before, as I remember testing with sizing and paint events installed. Should this work, or was I obviously doing something wrong (and somehow got away with it =)?
If your OnSize and OnPaint methods were after the DECLARE_EVENT_TABLE then it would have still been okay since they don't have to be public. It's things like this that make me love Python so much.
Oh, one other thing. Right now the extension module installation process doesn't work quite right, because the site-packages modules are now versioned and setup.py wants to install to "wx" and "wxPython". Maybe on *nix we could have wx and wxPython sym-links that point to the correct folders?
You can get distutils to use the extra path by passing the extra_path parameter to setup. I manage it like this in my setup.py:
if INSTALL_MULTIVERSION:
EXTRA_PATH = getExtraPath(addOpts=EP_ADD_OPTS)
else:
EXTRA_PATH = None
and then pass "extra_path = EXTRA_PATH" in the setup() call. Currently EP_ADD_OPTS defaults to false, but I've been using it in all the installer builders with a True value, so I'll be changing the default. (It controls whether the extra path is like "wx-2.5.3" or "wx-2.5.3-osx-unicode".)
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!