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. 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. What approach we take depends largely on who shows up and what they feel comfortable with. > 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 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. -- Nick
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4