[Pythonmac-SIG] Re: Mac newbie

[Chris Barker]

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

Chris.Barker at noaa.gov