[Pythonmac-SIG] Re: Mac newbie

[Bob Ippolito]

On Feb 14, 2005, at 2:05 PM, Chris Barker wrote:

> Bob Ippolito wrote:
>
>>> 4.  AnyGui seemed like a really good idea to me.
>> Lots of good ideas never get the attention and effort they deserve.
>
> Except that AnyGui was never a good idea. A wrapper around a wrapper 
> around a wrapper around a ..... just too much! As far as I can tell, 
> there are two good ideas:
>
> 1) a toolkit written from scratch that draws it's own stuff on all 
> platforms. To get performance, much of needs to be written in a lower 
> level language: al la QT, GTK, Fox, etc....
>
> 2) a toolkit that wraps the native widgets on all platforms, also 
> needs to be written largely in a lower level language: al la 
> wxWidgets.
>
> What would be nicer than any of the existing alternatives is one 
> written specifically for Python. The problem with that is that it has 
> a smaller audience, so may never get done. PyGui has promise, but has 
> a long way to go.
>
> http://nz.cosc.canterbury.ac.nz/~greg/python_gui/

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.  All the tight loops are already in 
the lower level and anything on top of that is going to be 
insignificant unless it's done horribly wrong.  Especially when using 
native widgets.

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.)
2. Thin Python FFI layer (i.e. ctypes or PyObjC -- ultimate 
flexibility, minimal non-Python code)
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)
3. High level Python layer (exposes a nice interface for Python 
developers)

The benefit of an approach such as ctypes or PyObjC is that there's 
essentially nothing you can't do from Python.  The price you pay is 
that the interpreter can crash if you do the wrong thing (this happens 
in platform code, anyway), and due to the nature of FFI such things can 
be confusing to track down from the platform debugger if you don't know 
what you're looking for.  Appropriate safeguards would be installed in 
the high level layer, rather than in C/C++ code.

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.

> > For IDEs written in Python, in-process interpreters and
>> debuggers can cause the IDE to crash, halt, or behave strangely.  
>> Unfortunately this is common practice.
>
> Very good point. This locks you into using the same GUI toolkit that 
> the IDE uses, severely limiting the market.

Not only does it lock you into a GUI toolkit, but the crashes, halting, 
and strange behavior is definitely a very big problem.  On Mac OS X 
especially, where each process can have exactly one or zero menus.

-bob