I am currently embedding python in a c++ wx app. I am planning to use
SWIG to generate the wrapper code.
When I checked out how wxPython was working, i noticed that a customized
version of SWIG is being used... wxSWIG.
Would it be, in general, better to use wxSWIG to embed python in a c++
app? What are the changes and customizations done to wxSWIG as compared
to normal SWIG?
Thanks in Advance!!
Regards
···
--
K S Sreeram
Director of Research
Tachyon Technologies Pvt. Ltd.
I am currently embedding python in a c++ wx app. I am planning to use
SWIG to generate the wrapper code.
When I checked out how wxPython was working, i noticed that a customized
version of SWIG is being used... wxSWIG.
Would it be, in general, better to use wxSWIG to embed python in a c++
app?
If you need to use wxPython from your embedded Python code then yes, you need to use wxSWIG. If you are only exposing your own classes and whatnot then you don't need to.
What are the changes and customizations done to wxSWIG as compared
to normal SWIG?
There were a lot of little tweaks to how the Python proxy class code is generated, including a couple new %pragma statments for adding code to a Python class or to a specific method.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Hi,
Since SWIG has developed quite a lot since version 1.1 - and 1.3 is actually
(semi-officially) now called stable ! (as in: the current RELEASE version)
I was wondering: Are there any plans to move wxSWIG to 1.3 ?
If wx's SWIG could be merged again with the "real" swig - that wound be
wonderful.
Just curious,
Sebastian Haase
···
----- Original Message -----
From: "Robin Dunn" <robin@alldunn.com>
To: <wxPython-users@lists.wxwindows.org>
Sent: Tuesday, June 03, 2003 2:01 PM
Subject: Re: [wxPython-users] wxSWIG info
K S Sreeram wrote:
> Hi all
>
> I am currently embedding python in a c++ wx app. I am planning to use
> SWIG to generate the wrapper code.
>
> When I checked out how wxPython was working, i noticed that a customized
> version of SWIG is being used... wxSWIG.
>
> Would it be, in general, better to use wxSWIG to embed python in a c++
> app?
If you need to use wxPython from your embedded Python code then yes, you
need to use wxSWIG. If you are only exposing your own classes and
whatnot then you don't need to.
> What are the changes and customizations done to wxSWIG as compared
> to normal SWIG?
There were a lot of little tweaks to how the Python proxy class code is
generated, including a couple new %pragma statments for adding code to a
Python class or to a specific method.
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org
Hi,
Since SWIG has developed quite a lot since version 1.1 - and 1.3 is actually
(semi-officially) now called stable ! (as in: the current RELEASE version)
I was wondering: Are there any plans to move wxSWIG to 1.3 ?
If wx's SWIG could be merged again with the "real" swig - that wound be
wonderful.
Yes, I plan on switching in the wxPython 2.5 timeframe.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
If you need to use wxPython from your embedded Python code then yes, you
need to use wxSWIG. If you are only exposing your own classes and whatnot then you don't need to.
Hmm. Thats really puzzling. How can using wxPython require me to use
wxSWIG for my interface code???
my wx app has either custom written wrappers (or plain SWIG wrappers),
and wxPython is built using wxSWIG generated wrappers.
How can there be a conflict in this scenario, and how will me using
wxSWIG for the app wrappers solve the conflict???
SWIG generates data structures to track the various classes that it wraps, and it is used for determinig if a particular opbject (via it's "swigified pointer") derives from a specific class or not. Your wrappers need to use this same scheme in order for the runtime to typecheck that some YourWindow class derives from wxPython's wxWindow class, for example. The way this meta data is created and used, (as well as the nature of the swigified pointers I think) has changed in 1.3.
Additionally, you need to ensure that you are using the same instance of the SWIG runtime that wxPython is using. It is part of the wxc module, but the important functions are exported via a funtion table using the Python CObject facility. #including wxPython.h and calling wxPyCoreAPI_IMPORT will take care of loading the wxc module and giving you a pointer to this function table, as well as a bunch of macros for using the functions in that table.
Finally, you need to deal with the Python global interpreter lock the same way that wxPython does otherwise you risk causing a deadlock. There are functions in the function table that help you with this.
Take a look at the wxPython/samples/embedding sample for details and some more notes and hints.
···
On Wed, 2003-06-04 at 02:31, Robin Dunn wrote:
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!