[Pythoncard-users] Kevin's PythonCard goals

[Kevin A. <al...@se...>]

In no particular order and with as much rambling as I can muster ;-), here
are some of my goals for what we're currently calling PythonCard. I'll
expand on some of these issues in other emails. Comment please.

A GUI application framework written in Python and using Python as the
scripting language for building apps.
Among other things this means that in HyperCard terms we aren't creating a
HyperTalk (xTalk) language clone. For a Python user it means that to
effectively use PythonCard they will need some familiarity with object
oriented programming. They will need to understand classes, objects,
methods, functions and the differences between them, at least in terms of
Python. The good news is that object oriented programming doesn't get much
easier than it does in Python. It lacks the discipline of strongly typed
languages so you can really create a mess if you want or accidentally, but
the power is there, so you just have to be pythonic and go with the flow.

Ability to leverage existing Python libraries with a minimal of fuss
This includes being able to put simple GUI front-ends on command-line tools
and interfacing to well understood Python libraries like NumPy and PIL, etc.

Simple apps should be simple and easy to build
I'm willing to give up some flexibility and power if it makes smaller apps
dramatically easier to build and maintain. I've stated this before, but
almost every sample application was done in anywhere from less than an hour
to an afternoon of work and a lot of that time was often spent on layout.
Later modifications were simple incremental additions, not rewrites. The
current framework is not a traditional Rapid Application Development (RAD)
tool, but because of the power and simplicity of Python it has enabled me to
make some useful stuff with very little planning. When I look at books that
spend hundreds of pages doing nothing but toy apps in tkinter it makes me
sad.

Cross-platform
I still think a cross-platform solution is the right thing to do, though it
puts some pretty severe limitations on exploiting the richness of the
underlying OS. I'm specifically talking about the major desktop OS
platforms: Windows (98/ME/NT/2K/XP), Windows 3.1 and 95 are not worth
supporting IMHO, Mac (Classic/OS X), and Linux. I'll add Solaris in there
since wxPython already supports it. I'm also going on the assumption that
there will be a Mac wxPython port soon and that we won't have to wait until
next year. The wxMac port of wxWindows is getting a lot of attention right
now on wx-dev.

wxPython
More on this in another message. The short story is that I still don't know
of any other cross-platform solution for Python that is as capable. If you
want to make the argument for supporting tkinter, do so now. If I'm missing
a different solution, please speak up as well. I'm not including Jython
since I consider that a completely different type of solution space.

Its the apps stupid
I'm not really that interested in building a better mousetrap, aka the
framework. My interest is really in having a great way of building apps in
Python. Consequently, I would like to have something usable yesterday, not a
year or two from now. When we started I promised that what we built along
the way would be usable on its own even though it was just a prototype and I
think that goal has been met. Any future work should be focused on results
with incremental improvements. I'm probably not willing to spend a month or
two designing a framework spec before starting to implement it, I'm just not
a good designer, I like to take too many shortcuts.

Multimedia support
This is a tough one because of the cross-platform issue. We can't use COM,
do QuickTime, or play back MPEG and MP3s in a standard way. We can play WAV
sounds files. The SDL library, which PyGame uses can play back some MPEGs
and MP3s and I have had some discussions and done a few tests with Pete
Shinners, the PyGame author, about how we might add those capabilities, but
there is still a lot of work to do.

Richedit control
Like multimedia this is another toughie due to cross-platform issues. It
turns out that under Windows, wxWindows/wxPython uses a control limited to
32K of text for wxTextCtrl. In order to get a 2GB text limit and styled text
in the same control you have to specify the wxTE_RICH and wxTE_MULTILINE
styles. However, under Linux the richedit control was coded specifically for
wxGTK and does not use a native control or have all the features of the
richedit DLL under Windows, so the wxWindows rich text API is extremely
limited. Typically, people are directed towards Neil's Scintilla in its
wrapped form if they want more control, but Scintilla, while nice for doing
a text editor is not nice for simply mixing styled text in the same control.
I have no idea what the wxMac situation will be. What I do know is that an
additional layer of logic is going to be needed to make styled text simple
and easy to use in wxPython. For speed reasons, whatever Python logic is
added to make the rich text control more useful will probably have to be
moved back to C++ at some point. Neil or Robin, please correct me on any
mistakes above.

Separate GUI descriptions and layout from source code
Mixing code and layout is not good. "Bad monkey, no banana!"

Graphical layout tools for widgets, menus, etc.

Runtime shell for interactive programming and output

Interactive editing while the app is running with reloads if possible,
otherwise a simple edit/run cycle.

Message Watcher
For those of you that never used HyperCard this may seem dumb. I also know
people that used HyperCard that never saw the point in the Message Watcher.
Think of it as just another debugging tool. As soon as I had the first
message watcher working in PythonCard I identified two event bugs in
wxWindows/wxPython. Who knows how long those have been around? It is also a
nice learning tool to see what is going on with events.

Native controls/widgets, so that apps look like native apps under each OS.

Helper classes in the framework
Find, transparent storage of data and metadata. These classes should
complement what is available in the underlying GUI toolkit, but not reinvent
something that is available via the Python Standard Libraries or a common
library such as NumPy.

Direct manipulation instead of Model View Controller?!
This is a separate thread. I don't mind MVC in the framework, but I am wary
of exposing it such that user code has to do MVC. While powerful and quite
standard these days, I still think that it is conceptually difficult to
grasp and can make simple projects difficult because of extra planning
required to do MVC right, but I'm an MVC newbie so what do I know? This
really deserves its own thread. I'll get back to this later today or
tomorrow.

Desktop apps are my focus
However, if we can do something that will allow more integration with web
solutions then that would be nice, but not at the expense of turning the
framework/environment into yet another web applications template tool, etc.
Python is not a full citizen in the browsers of today, so there is no point
in pursuing that area. The one thing we should seriously consider, which
Neil has brought up before is modeling our framework on the DOM, so that it
would be simpler to share layouts and program flow. Who knows, maybe someone
would even get inspired to write a Python to/from JavaScript translator if
the document/application models were compatible.

A component architecture
At one point I thought we might be able to do this with XPCOM. Unless I'm
missing something, XPCOM and PyXPCOM are comatose. I posted recently on the
XML-RPC list about XML-RPC for local app to app communication and got a very
disappointing response. The Mac has AppleEvents and Windows has COM and COM
works extremely well and has been very successful. However, it is too hard
of a problem for even a small developer group to tackle, so I'm not gonna
waste much more time worrying about a cross-platform solution.

HyperCard as inspiration, not gospel
I've used a lot of IDEs and just about every major OS available since 1979
or so. For me, HyperCard was the environment that was the most pleasurable
to program in and use to build stuff. Ultimately, its limitations killed it,
but it was fun and if "you got it" then you could be extremely productive
with it. I think that the combination of a scripting language and a simple
environment were the reasons it worked well. If you wanted to build
something beyond its capabilities then it could be trying, for one you can
to resort to external commands and functions. I still like the name
PythonCard, but another name might be more appropriate.

ka