[Dev] ZODB + wxPython framework

[Michael R. Bernstein]

On Mon, 2002-10-28 at 21:34, Michael R. Bernstein wrote:
> I just ran across this desktop application framework called PyFrame:
> http://www.pyframe.com/
> 
> Seems like it could be vaporware, but I'm CC'ing the contact email for
> the site just in case.
> 
> If it's *not* vapor, it looks promising, and may be useful for
> developing Chandler.
> 
> Or not.
> 
> Michael Bernstein.

I received a reply from Jeff Sasmor, the developer of PyFrame, but
though he CC'd the list, I didn't see his reply here, so I'm forwarding
it back to the list.

-----Forwarded Message-----

From: Jeff Sasmor <jsasmor@gte.net>
To: Michael R. Bernstein <webmaven@lvcm.com>, dev@osafoundation.org
Subject: Re: ZODB + wxPython framework
Date: 29 Oct 2002 08:52:11 -0500

It's not vaporware, but if you note on the title page of the website,
it won't be available till sometime next year. The alpha versions of 
it are quite operational, but there are a number of key features
that aren't implemented yet.

Here's some more info that I have forwarded to others who have
stumbled across a website that really shouldn't exist yet.

The whole premise was to bring the neat framework that
Zope provides the website developer to the world of
the application developer.

And it works quite well: you do everything within the environment;
even using external packages.  You can drop in an external package,
say, the mx tools package from egenix, and PyFrame converts it
to a bunch of PyFrame objects: Python packages and PythonMethods
and Documents for README files and such.
You can then import code from that package and its subpackages
from other PythonMethods and it all is stored within the ZODB.
Even packages that use prebuilt .pyd files (with some trickery)  work
just fine.

So, you can create entire applications within this framework
then use an export to create an export file (like a .zexp file in
Zope) which can then be re-imported into another instance of
PyFrame on another computer.

Aside from issues of changes between Python versions and the
usual issues about cross-platform compatibility, portability
should be much improved.

Developers can write things to extend the framework (which
is fairly tricky to do) or (more commonly) they can write general-
purpose apps  that will launch in a new process with a
fresh interpreter and the framework will be invisible to the end
user.

Distribution of the framework will be in a shrunken version
without docs and sources for PyFrame, Python, wxPython etc.
to save space. This is for end-users so they can DL
just the framework and whatever apps they want: the DL is
under 5 MB.

Developers will have access to what they need to develop within
and outside of the framework. There will be a debugger and
GUI-framework (wxPython) editor as well.

I don't think that this will be for everyone; i.e., I don't see how
those who use Python to develop for web-centric applications
could use it. It also breaks the development mode of many folks:
using CVS makes no sense within such a framework. However,
there are millions of people who don't use CVS (myself included).

The great advantage is the integrated environment, ease of installation,
and ease of distribution of programs that are created within the
framework. Distutils, while very flexible, is much too daunting for
many folks, and especially novices. One of the aims of the
PyFrame project is to make creating Python apps much
more like using Visual Basic: bringing more programmers into
the Python fold.


#--------------------------------
Jeff Sasmor
jeff@sasmor.com