[Python-Dev] SWT PyCon Sprint?

[Phillip J. Eby]

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 
>>>somewhat working...
>>
>>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 
ctypes-based module.


>>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* 
platform!)

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.