Re. PythonCard - was Re: Event-driven GUIs ...

[Chris Barker]

Robin Dunn wrote:
 
> But arguably not a *Good Thing*.  Mainly it just reduces complexity enough
> that one single ordinary human can develop, enahance, maintain, and find/fix
> bugs in the package and still have time for a real job and a bit of a life.
> SWIG doesn't generate the best code, but it means that there is around a
> quarter of a million lines of code that I don't have to maintain and debug
> by hand!
> 
> > It is a bad thing because you end up writing
> > Python code that is not natural (pythonic), and a whole lot more verbose
> > and complex than it needs to be.
> 
> Since I have a strong C++ background I look at the world with an intermixed
> C++/Python view, so I often have a hard time seeing the "non-pythonic"
> issues with wxPython but I know they are there.  I've addressed many of them
> at the SWIG layer and there have been a few contributions for the
> wxPython.lib package for some more pythonic things at the Python layer.
> I'll accept all contributed code that makes things easier.

Well, I'm one of the folks that have complained, and even suggested
improvements, but not yet contributed anything...

> I've recently had some ideas and added items to my todo list that will
> probably help out in this area, so I think this will become less of an issue
> over time.  On the other hand, for a large majority of things wxPython is
> used for it is fast enough already.

That's quite true. The one place we have problems is with drawing code:
passing LOTS of stuff to a DC within a Python loop is just too slow.
Klass' wxCanvas may help that out lot, I've been talking to him about it
quite a bit, and I'm looking forward to using it. For those interested,
check out:

http://www.xs4all.nl/~kholwerd/wxstuff/canvas/

It is a high level vector drawing canvas... it has a lot of promise.

> > wxWindows and Python also share a lot of duplicate
> > functionality: sockets, database access, process control, file system
> > manipulations, etc. etc.
> 
> Much of which can be turned off when compiling wxWindows, but there probably
> will always be some overlap with the current architecture.

Well, sure, it just seems redundant, and I think it would be hard to
decide which to use, particularly in a mixed C++/Python App. The current
architecture is really pretty darn good. It works. It works better than
any of the other alternatives that I know of (QT looks pretty procicing,
but the not quite open source issue is a problem, and they don'thave any
intention of supporting MacOS Classic)

I just think a truly integrated toolkit would be so much better, but
there is no way Robin (or any one person) could do it all himself, so
the current solution is a good one.

-Chris

-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------