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
