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.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
