[Python-Dev] SWT PyCon Sprint?
Phillip J. Eby
pje at telecommunity.com
Thu Mar 10 22:40:42 CET 2005
At 04:06 PM 3/10/05 -0500, Nicholas Bastin wrote:
>On Mar 10, 2005, at 11:00 AM, Phillip J. Eby wrote:
>>At 01:38 AM 3/10/05 -0500, Nicholas Bastin wrote:
>>>I realize that this is exceedingly late in the game, but is anybody
>>>interested in doing a Write-Python-Bindings-for-SWT sprint? It's been
>>>brought up before in various places, and PyCon seems the likely place to
>>>get enough concentrated knowledge to actually get it kicked off and
>>I'm certainly interested in the concept in general, though I'm curious
>>whether the planned approach is a GCJ/SWIG wrapper, or a javaclass
>>(bytecode translation)+ctypes dynamic approach. I'm somewhat more
>>interested in the latter approach, as I find C++ a bit of a pain with
>>respect to buildability.
>I'm open to either approach. I don't know a lot about JNI, so I was
>hoping somebody would come along for the ride who could answer certain
>questions about how SWT is implemented.
By design, SWT is pure Java with an as-thin-as-possible JNI wrapping of the
native platform GUI. It's akin to writing a pure Python GUI for Windows
using ctypes or simple Pyrex wrappers to directly call Windows C APIs.
The important thing to be aware of here is that this means that you can't
just take the SWT .dll's or .so's and put a Python binding on them, because
all you'd end up with is a wrapper to the Windows or Mac or GTK API.
I'll repeat this, because it's a common source of confusion about SWT: the
SWT implementation is *all* Java. The native dynamic libraries for SWT are
just the glue to be able to call platform API's, they do not contain *any*
high-level code. This is both good and bad. It's good in that you don't
have to worry about the JNI issue if you want to port SWT to another
platform, you just have to have a way to call the platform's APIs. It's
bad in that you can't just put a new language binding on the native
libraries and have an SWT port.
> A third option would be to grovel over SWT and implement an identical
> functionality in Python (pure-python plus ctypes), and make a mirror
> implementation, rather than a wrapper.
If you're going to do that, you might as well use javaclass to do the grunt
work of the translation, and simply replace the native library with a
>>An additional complication is that SWT is a different package on each
>>platform, so it's not so much "port SWT to Python" as "port SWT-windows
>>to Python", "port SWT-Mac to Python", etc.
>The API is identical for each platform, however, so depending on the level
>at which you wrapped it, this is only a build problem.
I'm just pointing out that the source code for each platform is
different. The native library for each platform is different. The native
libraries also expose different APIs on each platform, because they just
expose that platform's native API.
So sure, there's probably some code that's similar or identical, but the
whole point of SWT is that each one is a custom implementation for its
platform, as distinct from approaches like AWT, Swing, wxWidgets, et al.
>>(I assume that you're talking about porting to a JVM-less CPython
>>extension, since if you were to leave it in Java you could just use
>>Jython or one of the binary Python-Java bridges to access SWT as-is.)
>Yes, JVM-less CPython extension would be the plan.
Then here are the possible architectures, as I understand them:
Layer 1: Native Platform Interface
Option 1: Use the JNI libraries supplied with SWT (forces GCJ at layer 2)
Option 2: Create a Python wrapper for the corresponding APIs
* Possibly semi-autogenerated from JNI metadata
* ctypes, Pyrex, or C
Layer 2: SWT Java Implementations
Option 1: Compile with GCJ (requires JNI approach at layer 1)
Option 2: Translate Java bytecode to Python bytecode w/javaclass
Option 3: Translate Java bytecode to Pyrex or C (by modifying javaclass)
Option 4: Translate Java source to Python or Pyrex by hand (for *each*
Layer 3: Python wrapper (only needed for GCJ scenario)
Option 1: SWIG (needs a C++/SWIG guru)
Option 2: Boost::Python
Option 3: Plain C++
So as you can see, the choices are basically GCJ versus everything else,
but the GCJ approach forces C++ into the mix and requires good knowledge of
either C++ or SWIG, maybe both. But it only needs to be done once, and
should then be buildable on all platforms. OTOH, if I had the necessary
skills, I'd have probably already taken on the effort. It would be cool if
somebody created a SWIG wrapper generator that could pull the necessary
info from Java class files to make a GCJ wrapper. But as far as I know,
everybody who's wrapped Java libraries for Python using GCJ wrote their
wrappers by hand.
Anyway, this is now getting *way* off topic for Python-Dev, so if there
aren't any other interested parties we should take this off-list.
More information about the Python-Dev