Thank you for such a detailed answer.
Sounds like it might be easier to go with 2.5.1. Is this assumption correct?
···
-----Original Message-----
From: Robin Dunn [mailto:robin@alldunn.com]
Sent: Friday, April 16, 2004 3:15 PM
To: wxPython-users@lists.wxwidgets.org
Subject: Re: [wxPython-users] Extending wxPython/wxWindows with new C++
modules
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!
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org