Bob Ippolito wrote:
On Feb 14, 2005, at 2:05 PM, Chris Barker wrote:Except that AnyGui was never a good idea. A wrapper around a wrapper around a wrapper around a ..... just too much!
While I agree with the assertion that a large part needs to be written in a lower level language, I don't agree that wrapping a wrapper is going to be a performance problem.
It's not so much performance as complexity and the lowest-common-denominator problem. I"m pretty sure AnyGui is dead now anyway, and I've written a couple longer rants about this, but consider this:
AnyGuiTK is a Python wrapper around a Python wrapper around another scripting language, around and extension written in C, which is wrapped about the X11 API, which is emulated on other platforms.
AnyGuiWx is a Python wrapper around a SWIG wrapper around a C++ toolkit that is a wrapper around a native GUI toolkit.
When there's a bug, you've got a lot of layers that may be responsible!
It comes down to why? AnyGui has a flawed reason for being. NO one should care what toolkit is underlying their app at the bottom. What they should care about is;
The API The Look and Feel The Features The Platform support
AnyGUI had some potential to improve the API of the underlying toolkits but that's it. It makes much more sense to just write a better API wrapper around a toolkit that meets your other needs.
Ideally I'd propose a design like this:
1. Low level C/ObjC/C++ implementation (probably the native platform's toolkit, but could be wxWidgets, Qt, etc.)
wouldn't it have to be it it were X-platform?
2. Thin Python FFI layer (i.e. ctypes or PyObjC -- ultimate flexibility, minimal non-Python code)
What's FFI ?
2.5. Mid-level Python layer if necessary for a sane implementation of the high-level (might be overkill for PyObjC given how similar Objective-C and Python are)
Good point. The better the API you're wrapping, the less need for this.
3. High level Python layer (exposes a nice interface for Python developers)
This sounds a lot like PythonCard, actually.
1) wxWidgets
2) SWIG--wxPython
2.5) Some of the stuff wxPython adds: better dynamic binding syntax, OGL, FloatCanvas, other high level widgets.
3) That's what PythonCard itself is.
Wrappers generated with tools such as SWIG, sip, bgen, and Boost Python could also fit in for layer 2 -- but I think that a runtime solution is going to be better in the long run.
hmm. Is it possible to have a run-time solution for the more static languages like C++?
-Chris
-- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
[EMAIL PROTECTED] _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
