Schalkwyk, Johan wrote:
I'm working on a vision extension to wxWindows, that will display in
realtime a camera image in a wxWindow. In addition to this I'm adding
rudimentary vision algorithms and incorporating the open source compute
vision library from Intel. I managed to get a lot of this working inside
wxWindows using C++, but want to incorporate this into wxPython. I'm
familiar enough with SWIG to create my own C++/Python extionension, but not
familiar enough to know how to connect this to other libraries especially
wxPython where I need access the the wxFramePtr or other wx*Ptrs.
My Goal is as follows
- keep wxPython the same, i.e a single wxWindows and SWIG wrappers
- create a new DLL that links with the wxWindows DLL (i.e can do
this in C++ and create stand-alone programs)
- wrap new C++ classes (i.e extensions to wxWindows) with SWIG. I.E
create a new library, let's call it wxVision and load it in Python
- incorporate new C++ classes in to wx.lib.vision (as an example)
Are there any examples out there to attack this problem. I.E how do I expose
my SWIG implementation files to the wxPython definitions. I'm trying to add
a new class and make it look as if it was part of the original wxPython
class hierarchy.
Some details are different based on if you are using 2.4.x or 2.5.x, but in general:
1. Take a look at one of the contribs in .../wxPython/contrib in a wxWidgets/wxPython source tree, and also the coresponding section in .../wxPython/setup.py. You'll want to model your .i file and etc. similar to how these are done. In 2.5 I'm trying to make it easier to build 3rd party modules without being tied too tightly to the wxPython source tree, but it probably isn't all the way there yet.
2. You'll need to use the same version of SWIG as wxPython does. For 2.4 that is a wxSWIG fork that you can get from wx CVS using the WX_2_4_BRANCH tag and is located in .../wxPython/wxSWIG. For 2.5 I'm currently using SWIG from their CVS as of around 02/20/2004, plus some of my own patches located in .../wxPython/SWIG. See the readme in that dir.
3. You need to ensure that your extension and wxPython extensions are all using the same instance of the wx DLLs or shared libs.
4. Your extension needs to #include wxPython.h. For 2.4 this is in .../wxPython/src, for 2.5 it is installed along side the wx headers if you use one of my -devel pacakges, and should be done as
#include <wx/wxPython/wxPython.h>
5. wxPython.h contains a bunch of macros that among other things replace direct function calls to the SWIG runtime API to indirect function calls via a function pointer in an API struct. A pointer to that struct is imported at runtime from the core wxPython extension module. This is my way of ensuring that all extensions are using the same SWIG runtime and so type-checks and such are all using the same code/data. On of the macros replaces the first function called in a SWIG-generated init function with code that does that import for you. However if you need to use any of those API functions in another source module that is not generated by SWIG then you need to arrainge that wxPyCoreAPI_IMPORT is called before any of them are used from that module.
6. Your .i file needs to be able to %import one or more .i files from wxPython's set of .i files. This is so SWIG knows about the types of base classes you may be using, to get all the typemaps that I have defined, and etc. So you need to add a -Ipath to swig's command line so it can find these files. For 2.4 they are located in .../wxPython/src. For 2.5 using an installed set of wxPython headers they are wherever the wx headers are, plus "wx/wxPython/i_files"
7. See also http://wiki.wxpython.org/index.cgi/ExtendingAndEmbedding for a bit of information about how to handle the GIL to be compatible with wxPython. If you are properly importing the wxPython .i files then the Python to C++ calls (1) code will be handled for you by SWIG. When you do anything in your own code that manipulates Python objects or calls Python methods, etc. then you'll need to wrap that code as in (2).
That's all I can think of right now. If you run into problems just ask.
ยทยทยท
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!